[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120609125854.GC17860@port70.net>
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.
