Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 29 Nov 2012 09:03:32 +0100
From: Szabolcs Nagy <>
Subject: Re: Design idea for subarchs/abivariants

* Kurt H Maier <> [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

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.