From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1012 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: printf POSIX compliance Date: Fri, 8 Jun 2012 11:53:22 -0400 Message-ID: <20120608155322.GR163@brightrain.aerifal.cx> References: <20120608144423.GN163@brightrain.aerifal.cx> <20120608145519.GP163@brightrain.aerifal.cx> <20120608150618.GB17860@port70.net> <20120608152935.GQ163@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1339171082 14967 80.91.229.3 (8 Jun 2012 15:58:02 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 8 Jun 2012 15:58:02 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1013-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jun 08 17:58:01 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Sd1ZW-0004ki-6l for gllmg-musl@plane.gmane.org; Fri, 08 Jun 2012 17:57:58 +0200 Original-Received: (qmail 23779 invoked by uid 550); 8 Jun 2012 15:57:58 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 23771 invoked from network); 8 Jun 2012 15:57:58 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1012 Archived-At: On Fri, Jun 08, 2012 at 04:43:45PM +0100, Reuben Thomas wrote: > On 8 June 2012 16:29, Rich Felker wrote: > > > > Thanks; I think that settles it then. I wonder if they'd accept a > > patch upstream to fix this bug.. > > The answer is very much "yes", in my experience (I'm not a gnulib > developer, but I have submitted patches on several occasions). > bug-gnulib@gnu.org! I was referring to m4, which seems largely unmaintained, not gnulib. My view is that it's a bug to be directly using gnulib functions that are not (and cannot be) portable and that presumably only exist for the sake of implementing replacement functions on a finite known set of broken systems for which the existing code suffices. Of course it would be nice if gnulib could do something to prevent this sort of situation from arising in the future too (and fix the bugs I found in the tests and reported elsewhere in this thread), but since gnulib is integrated into packages that use it, resolving even those issues also requires getting the new fixed version deployed into the affected packages. Rich