Re: [RFC][PATCH] getname_maybe_null() - the third variant of pathname copy-in

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 19 Oct 2024 at 10:11, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
>
> There'd been an example of live use of that posted upthread:
>
> https://sources.debian.org/src/snapd/2.65.3-1/tests/main/seccomp-statx/test-snapd-statx/bin/statx.py/?hl=71#L71
>
> "" rather than NULL, but...

Note that outside of a library, I'd argue that using NULL is an active
bug, and should not be supported.

It's purely a Linux extension, after all.

That said, I do think my "what if a library implements fstat() using
fstatat()" argument could equally well be "what if a library does a
Linux-specific optimization and uses NULL instead of the empty
string".

So I guess it would be entirely valid for a Linux libc to do something like

       int fstatat(int dirfd, const char *restrict pathname,
                struct stat *restrict statbuf, int flags)
        {
                if ((flags & AT_EMPTY_PATH) && !*pathname)
                        pathname = NULL;
                return SYSCALL(__NR_fstatat, dirfd, pathname, statbuf, flags);
        }

so yeah, I guess it's however we just decide to document it.

               Linus




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux