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=ham 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 496F32FD18 for ; Wed, 18 Sep 2024 04:57:35 +0200 (CEST) Received: (qmail 26458 invoked by uid 550); 18 Sep 2024 02:57:29 -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 26417 invoked from network); 18 Sep 2024 02:57:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net; s=s31663417; t=1726628240; x=1727233040; i=nullplan@gmx.net; bh=QU/fw4rZsBfgT4IiQCRdfDmQlfwUuPeo/9yrTqXwVJc=; 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=gdblCbvbjCTKTULfl3hlW/FxCo3kQAbWFOhWLNNmChTUU+ueWXx8JtHGtRQtZltG Krpp2v9heqlUOL2WZl5cWafvZrQD5whNUoue0oIC9IMuyDBrRx59OoSaNNmmxN7Fa wNSTmPTGODPzWv9D/h7nlLpnbdU6V5lgD+FYHttZb9ie7Vw0U/w8jnC10P5iNavx9 0oa2VHFSyfT0opGhQ29Pzm7Z0YpDWU/oSYO3KRap8mZ7PonKmkH0AS6n2X83zucW9 j6wOM4zRp3rdpO2szas3Y482UnQMjPB3cr5EZgWI+xwBqKFo727pjRdUzkQofjsJO xNsDk66eisGZLNtZLA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Wed, 18 Sep 2024 04:57:19 +0200 From: Markus Wichmann To: musl@lists.openwall.com Cc: Alex =?iso-8859-1?Q?Benn=E9e?= , Brian Cain 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: <5179cce6-b63b-4687-8f25-f02a5fd93679@quicinc.com> X-Provags-ID: V03:K1:K7QO94iI1jMf94VmLtJcFBreZEEURiO3rrseIBCNdtnu4tChG9C +bWsCwCEcsJaOB5mKv7Jqav9JSRLsemNo/PQGK8ClqSI0TVciWjpqiWcRPHs35V7RWnUKKs nkP0wuxvwtX9fudjFASSP3a0cC6L3g+KGh1waJfKRRcV7q68dg95fxgeIBy0CVsFhzUzW0r bODLLBCfgsxfEqPozm47A== UI-OutboundReport: notjunk:1;M01:P0:HHTwQ7piDBA=;No6lb1E3O3w/HphcFiUKzD8xXK7 xRHBr1dGxf5O1A8oe3EzWaSirSa6SAO/mKGB1VABdubVToy8IMZOjONXKleTD+sSb3v4tNLHs BtF0Vozms+5REthz8xe81sw4SmjzIIv/VxthJInUFCzrGI+tBnvI1Li7tzxr2JXd+F674XHxO N29q004b/H1iK/qM7ko2P+fgpFAQeP2N/NY+kxKuwHjIFkt6jX/xMBobvCSeOybDw7IbLNAxl A0+K5Q/Aic/VcIqf24+Ph56bZe8OpvoGei2zau9gUnh51MmOxAmyYZjYmGZNvkJFb9SZ/QzEF BQzcRp8U0xgnKYY7FPUxndLAqnbyteeakWMx7LXBciATMxAG0uqO+1fWb1SbwqjDo+7rYtwYS 3RCSkymULjhfXJDDGZrp5MLZXWWpmcDSyWfnkcRe3KSw9+nZCNzsjJtwSnfujjLJJzpNVEGDF ImiJLgyIB1t9k/BQQdgXm5QltBQhY2lIQ4l2EJnU7bHOQlO+U8PtVNzdWy77U7HB8e7DnGDcS 6pGCarUn5p2+rQpY4Y36p4O68sTZopoGHru1nZ2ZODpo6JeHPqXNbHv1noDZJATOK3LhRoxiO jx2eJAhkYasjl1kpMIO9F4Ud4xjL9T0bjjlIYOju8XwJu0emDMlOQK8sQCJm24PdoIQXmJhoK BgHnvQjFFIAk65IBWqbuVpN6tCfPTk2CU1Am381rVeP7FjB+urKRPxfSeEkxRKnPKfOqArBcG AODDQaVzyO2ZkBHYiuC3brJlLHe2wRpzUW8NnwjDDYZFZqDBPeMTEGbGYzLBYA9PH5peZwFDI w+CKaEN7WGnAkBxBE/h8h/wwYgdZe8VlbmJEVtWIrG9vo= Subject: Re: [musl] _GNU_SOURCE and _LARGEFILE_SOURCE 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".=A0 Is that intended to be the ca= se > generally?=A0 I ask because in 25e6fee2 (remove LFS64 programming interf= aces > (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 b= e a > very short-term measure and that the macros be removed entirely in the n= ext > release cycle." > > This comes up because in the QEMU project, there's a linux multiarch tes= t > case that uses readdir64 and it does define _GNU_SOURCE but does not def= ine > _LARGEFILE64_SOURCE and as such the cross compiler complains that there'= s no > declaration of readdir64 before the call site.=A0 I suppose that the tes= t case > would be more portable if it defined _LARGEFILE64_SOURCE.=A0 But I'd als= o be > happy to send a patch to musl that could have _GNU_SOURCE imply > _LARGEFILE64_SOURCE (again?) if that's desired.=A0 But - I gather that > defining the macros is not what we want.=A0 Instead of macros I should a= dd > 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! Ciao, Markus