From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=unavailable autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id E30712FD56 for ; Wed, 18 Sep 2024 16:24:30 +0200 (CEST) Received: (qmail 8053 invoked by uid 550); 18 Sep 2024 14:24:24 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 8019 invoked from network); 18 Sep 2024 14:24:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net; s=s31663417; t=1726669454; x=1727274254; i=nullplan@gmx.net; bh=Gbue+QmBNPidQnGB+6lRsgUJfELHHzWXieIQM3gd5GI=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To: cc:content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=Uc+AgA91p37pN9vsCIhDuShFNEZ0bUIJ4KIm/5Qn2NC8RfDAJMqcelFwyocVm7UQ UDjeuSOIOJo3IVH9XFwQ5v6wakyS/IRqCn6dDvbsMOZaMChqhWTkMucdRxEAVv1xT 8X1FWzRUqX0rU7s56I84/h6rJz83mHGfQzmJ2SGZYOqHD1vgCiDo0baQwP4jonmWg sSNYLNNNdTGg6QR9HWd+81AXeF5OtUjHUyTnAKg1NJnSJ+MoD5/+rbE8Ik1P4j9cC Leza1HbwRL/Z2J5/PwcBWmpZXFbiWe32ZEAiSSl+b1twF+dg1Hg8Zyu+Bc2AqkBLe qoXgjn23YMcj+w/faQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Wed, 18 Sep 2024 16:24:11 +0200 From: Markus Wichmann To: musl@lists.openwall.com Cc: Brian Cain , Alex =?iso-8859-1?Q?Benn=E9e?= Message-ID: References: <5179cce6-b63b-4687-8f25-f02a5fd93679@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: X-Provags-ID: V03:K1:RVjUBsgFNWNtoxnO5EWcML7rQfjDAs3PAnBqiQErY+KPhJq+qbD Y3eYmcRtxw7/i81qNh52PXcwwJ2SRyBssVScvQmpOjmY2j4BscqijUCb3L5/O5eD8lYU1BU 9/gszZiWioYVrOBpIm6Zg4QKDF8QVVIZUYY51Q9zrr565UgVAZqhCbeksl50u2rApv8UUpr X/8kHfGdE6lSUApALBIaQ== UI-OutboundReport: notjunk:1;M01:P0:CmoF9YElWw0=;8ThrFXKUFHTWTHFAxxXCQMLelr9 h6EdWLRDWUNCg1ufZoSXBh1RIT2XAG11EZ5Q3WkHg84yJtfiEc4eDWBEkrAl9BK9cznMHtQhD rayrXzWs7PxNjhaOcMzLv3WIu0p+ThKmYtItcBOgACiJ9Ag/4639599LlXhMu5+47Ng+G/hg4 UhMPNBh1Au0ZmKzQdh8pCU42HYth9iBS5xKFUt5hpFbSwCS1PUn3ltVNKHN4u+QIkIulph/Dp XBsWm/B4e+zg151mCR2IBg24fL16PgG6WZE6xM6zravqg+mq6xiQlblFZBDcdV6s+L9Ih+y1i 4kebxASZCbU9M80gIcuWAvKi/q6fGdSTy/FkiG19vNTdlHq28ainAluWUGJBQ0IZITOeaikkT tMUVjwSEu78MmtqlhF+PWF9VP+KghsSkr4dmM9xK+jjrXyG6gPHFJGVmQexQHb60wVrRkABAg Fmoumumfs1RTVLk4uYI0w5P3Iu7392O3ApdDkc6zknq2SR3doPxcj5PIBkibHmrNxtdgdvCbm aSahP80heScUkfPOoKuGiE0lkP9by5JB2ZhrUjUKvy7UlqRYRVmJkTrfXelVUUwVYhdy/3KxD Ze5egAEZ2/zLh9uFoBTf83P1zfuPujc6QE0ab1zAokk4v0WnlpzQlty37RYVXFSLuFhwwJkGZ 1UzdzjLvh0T3cL6jEx4Fu0GNbLPq9BO7w+ycZ8pa0GRCa4z9l9of3kwLx8lPex0wMOpKIARFX 3oIxpwbxwgTtrJFtrwJyTyrek4lbKaixd/Ydc+x+PJeb16o3lz+/nO2c7BrNaeo6fPa/DvdU2 OkzpSy+a4aoAMI1c/7E/4SDyslQpWBzmGZXaDeXbJ+OlU= Subject: Re: [musl] _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?=A0 But at one = time > readdir64 (et al) mappings were provided for _GNU_SOURCE and those now > remain but only under _LARGEFILE_SOURCE.=A0 At some future date those ma= ppings > 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 POSI= X.=A0 > 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.=A0 But when using that define, gl= ibc's > type definitions for off_t (et al) will be such that they (1) can be use= d to > represent enough values for large files among 32-bit and 64-bit targets, > even when calling readdir-not-readdir64 and (2) are compatible / corresp= ond > with musl's type definitions?=A0 The wording of that last part is > not-quite-right, but I am capturing some of the essence there? "we'll en= d 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=3D64 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) =3D=3D 8, you don't need readdir64() at all. Ciao, Markus