[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ed35ca19-672f-4288-b5f7-7cc46264eea0@quicinc.com>
Date: Wed, 18 Sep 2024 00:06:44 -0500
From: Brian Cain <quic_bcain@...cinc.com>
To: Markus Wichmann <nullplan@....net>, <musl@...ts.openwall.com>
CC: Alex Bennée <alex.bennee@...aro.org>
Subject: Re: _GNU_SOURCE and _LARGEFILE_SOURCE
On 9/17/2024 9:57 PM, Markus Wichmann wrote:
> Am Tue, Sep 17, 2024 at 07:29:17PM -0500 schrieb Brian Cain:
>> In the "WHATSNEW" text, there's an item from 0.9.2 that states "- make
>> _GNU_SOURCE imply _LARGEFILE64_SOURCE". Is that intended to be the case
>> generally? I ask because in 25e6fee2 (remove LFS64 programming interfaces
>> (macro-only) from _GNU_SOURCE, 2022-09-27) it stated "portable software
>> should be prepared for them not to exist" and "the intent is that this be a
>> very short-term measure and that the macros be removed entirely in the next
>> release cycle."
>>
>> This comes up because in the QEMU project, there's a linux multiarch test
>> case that uses readdir64 and it does define _GNU_SOURCE but does not define
>> _LARGEFILE64_SOURCE and as such the cross compiler complains that there's no
>> declaration of readdir64 before the call site. I suppose that the test case
>> would be more portable if it defined _LARGEFILE64_SOURCE. But I'd also be
>> happy to send a patch to musl that could have _GNU_SOURCE imply
>> _LARGEFILE64_SOURCE (again?) if that's desired. But - I gather that
>> defining the macros is not what we want. Instead of macros I should add
>> declarations for readdir64() and its LFS64 friends, but only when
>> _LARGEFILE64_SOURCE is defined?
>>
>> -Brian
>>
> The LFS64 interfaces are not in POSIX, so you cannot assume they exist.
> Rather, you can test for their existance with a configure test, and if
> it fails fall back to the portable interface. Or just use the portable
> interface in the first place.
>
> If you want to compile portable code on glibc, then define
> _FILE_OFFSET_BITS to 64 and you get the exact same interface!
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
Content of type "text/html" skipped
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.
