From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1037 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: printf POSIX compliance Date: Sat, 9 Jun 2012 14:58:55 +0200 Message-ID: <20120609125854.GC17860@port70.net> References: <20120608144423.GN163@brightrain.aerifal.cx> <20120608145519.GP163@brightrain.aerifal.cx> <20120608150618.GB17860@port70.net> <4FD22C6C.5040704@barfooze.de> <20120608193357.40fb538d@newbook> <20120609024556.GY163@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 1339246749 22114 80.91.229.3 (9 Jun 2012 12:59:09 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 9 Jun 2012 12:59:09 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1038-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jun 09 14:59:08 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 1SdLFz-0006BL-1v for gllmg-musl@plane.gmane.org; Sat, 09 Jun 2012 14:59:07 +0200 Original-Received: (qmail 28137 invoked by uid 550); 9 Jun 2012 12:59:06 -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 28129 invoked from network); 9 Jun 2012 12:59:06 -0000 Content-Disposition: inline In-Reply-To: <20120609024556.GY163@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1037 Archived-At: * Rich Felker [2012-06-08 22:45:56 -0400]: > On Fri, Jun 08, 2012 at 07:33:57PM -0700, Isaac Dunham wrote: > > Of course, I know this isn't the right place to discuss such > > things--that would be for gnulib. > > Actually I don't think it's very off-topic here. This is certainly a > major affected community that has an interest in solving the problem, > and Reuben seems familiar with gnulib and the developer community and > interested in helping us find solutions and get them integrated. What > is the next step we should take? Posting to the gnulib mailing list or > bug tracker, or contacting somebody directly? > i don't like the gnulib approach to portability 1) it implements broken functions which simply must not be used in an application with portability requirements (eg alloca is implemented using assumptions about the stack mechanism and invokes undefined behaviour) 2) instead of sharing code between platforms they use ifdefs and depend on internals of the implementation (eg. broken gnu stdio functions: gnulib will never work on a new platform out of the box, you have to port it whenever there is a new libc or even a new version of a libc) 3) they duplicate a lot of the libc writing effort and provide bad quality code (eg. math functions: a mathematical software will only be portable if libm is high quality so if portability matters you need a libm written in portable c code (and maybe even softfloat emulation) for non-mathematical software probably a simple naive implementation is ok, but again it could be a separate 'libmdummy' written in clean ansi c and it could be used everywhere, so the same code gets tested on all platforms what gnulib gives you is mostly dummy functions with inconsistent quality, randomly pulled in depending on the target platform which means math code with gnulib can easily explode whenever high accuracy, correct nan handling or fenv support is required) in my opinion the more correct approaches to portability are 1) have a high quality libc (like musl) and port it to all the required targets (eg by emulating syscalls) 2) write the application with portability in mind: instead of using posix api use a 'libportability' api that covers enough areas so the application can work and simple enough so it can be implemented on any target (so eg. it has no alloca and freadahead in it, and only has limited form of networking, process or file management etc) these approaches are scalable because the platform specific code is minimized (the difficult part of the code is the same on all platforms)