Date: Sat, 9 Jun 2012 14:58:55 +0200 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Subject: Re: printf POSIX compliance * Rich Felker <dalias@...ifal.cx> [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)
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.