[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zurii1PHFV_p_Qrl@voyager>
Date: Wed, 18 Sep 2024 16:24:11 +0200
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Cc: Brian Cain <quic_bcain@...cinc.com>,
Alex Bennée <alex.bennee@...aro.org>
Subject: Re: _GNU_SOURCE and _LARGEFILE_SOURCE
Am Wed, Sep 18, 2024 at 12:06:44AM -0500 schrieb Brian Cain:
> Okay, this is a bit new to me, so let me see if I am following along:
>
> musl defines a readdir symbol and no readdir64 symbol, because readdir64 is
> not specified by POSIX only by Single Unix Specification? But at one time
> readdir64 (et al) mappings were provided for _GNU_SOURCE and those now
> remain but only under _LARGEFILE_SOURCE. At some future date those mappings
> might no longer be provided? And musl does not want to take patches that
> define a readdir64 symbol because that would be beyond the scope of POSIX.
> Applications that want to be portable among POSIX targets can define
> _FILE_OFFSET_BITS to 64 and this will have no effect on musl type
> definitions nor function declarations. But when using that define, glibc's
> type definitions for off_t (et al) will be such that they (1) can be used to
> represent enough values for large files among 32-bit and 64-bit targets,
> even when calling readdir-not-readdir64 and (2) are compatible / correspond
> with musl's type definitions? The wording of that last part is
> not-quite-right, but I am capturing some of the essence there? "we'll end up
> with those same semantics that musl has in the absence of _GNU_SOURCE /
> _LARGEFILE_SOURCE" maybe?
>
>
> -Brian
That is all largely correct. See, the only reason for readdir64 to exist
is because originally, ino_t was defined as the system word size, and
readdir returns inodes. So glibc added a type ino64_t, and a readdir64()
that returns pointers to struct dirent64. Now they've changed to
defining ino_t to either a system word or a 64-bit word depending on the
state of _FILE_OFFSET_BITS. And I don't know what magic they use to
redirect the calls to readdir() accordingly.
All of which is mostly pointless, since the inode as returned by
readdir() can't be used for anything by userspace. If the directory
entry is a mountpoint, then the inode number given is not even the same
as the number stat() would return.
But anyway, this means:
- there has never been a combination of Linux and libc version that had
anything other than 64-bit inodes (and file offsets) on 64-bit targets
- on 32-bit targets, musl always defines inodes and file offsets, and
glibc does the same when _FILE_OFFSET_BITS=64 is defined.
- the only reason to use the LFS64 symbols is compatibility with (at
this point) really old glibc versions on 32-bit targets.
Note that you can just use compile tests to see if you need the LFS64
symbols, and if they are available. If sizeof(ino_t) == 8, you don't
need readdir64() at all.
Ciao,
Markus
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
