From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 29377 invoked from network); 17 Apr 2023 19:40:13 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 17 Apr 2023 19:40:13 -0000 Received: (qmail 22234 invoked by uid 550); 17 Apr 2023 19:40:10 -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 22196 invoked from network); 17 Apr 2023 19:40:09 -0000 Date: Mon, 17 Apr 2023 15:39:57 -0400 From: Rich Felker To: Robert Clausecker Cc: musl@lists.openwall.com Message-ID: <20230417193956.GO4163@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] getpwuid() calls getline() which may be redefined On Mon, Apr 17, 2023 at 06:50:06PM +0200, Robert Clausecker wrote: > Greetings, > > I'm the maintainer of schilytools [1], a suite of tools including > cdrecord, mkisofs, star, smake, and others. To produce Linux > binary releases for our users, I investigated building static > binaries with musl and found that the star command experienced > problems [3]: when built with > > smake LINKMODE=static LDOPTX=-static INS_RBASE=/opt/schily SHLIB_BUILD=\# > > the program hangs reading from stdin. With the help of psykose > from your IRC channel, we found that this is due to getpwuid() > calling getline(), a symbol which this program uses for a custom > function with a POSIX-incompatible signature. This use of the > getline() symbol dates back to UNOS [2], an early UNIX close. > > We'll try to work around this issue, likely by renaming our > getline() to something else. I have filed this bug report with > you so you may decide if you wish to route the getline() call > through an internal symbol alias, proofing your library against > incompatible external redefinitions. Thanks for the report. getline has been POSIX for 15 years now, and we don't aim for namespace-conformance to non-latest versions of the standard. Namespace-guarded symbols are only used where we want to implement one function in terms of another whose name isn't reserved under the same standards-profile. Just renaming the function on the application side to bring it up to modern standards is the right fix here. (And it's good to hear somebody's still maintaining Schilly's stuff!) Rich