[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20121129080332.GN10895@port70.net>
Date: Thu, 29 Nov 2012 09:03:32 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: Design idea for subarchs/abivariants
* Kurt H Maier <khm-lists@...ma.in> [2012-11-28 19:22:51 -0500]:
> I'm asking this to be educated, rather than to make a point: why is a
> system like this preferable to the way plan9 libc is written, which as
> far as I can tell uses no ifdef at all?
i looked at this
it seems the plan9 and musl approach is similar
in the sense that they avoid unnecessary ifdefs
(putting arch specific stuff in separate dir etc, plan9
has union mount, musl uses a bits symlink in case of
headers)
they both use ifdefs for feature test macros
(obviously it's much less needed in plan9 but see the
ape implementation and it has some, musl needs a lot)
they both use ifdefs for typedef and include guards
(plan9 only uses them in ape, this is unavioidable in a
posix libc)
musl has to use ifdefs for some compiler specific features
(plan9 don't need this, they have their own compiler)
now musl will need to use ifdefs for some arch parameters
(endianness, soft vs hard float, long double,..)
plan9 libc does not need these because they don't implement
such things (there is no soft float or long double support,
no fenv, no endian dependent api etc)
but plan9 has ifdefs for arch specific options as well
(eg in driver code) just not in the libc
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.
