[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121129012107.GV20323@brightrain.aerifal.cx>
Date: Wed, 28 Nov 2012 20:21:08 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Design idea for subarchs/abivariants
On Wed, Nov 28, 2012 at 07:22:51PM -0500, Kurt H Maier wrote:
> On Wed, Nov 28, 2012 at 07:10:42PM -0500, Rich Felker wrote:
> > Yes, I thought about this too and even started writing the email that
> > way before deleting what I wrote and rewriting it. I was trying to
> > avoid more nested and conditional inclusion, but I don't think it
> > would actually be too costly to do it the way you proposed.
>
> 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?
Right now, musl uses separate bits headers for each arch rather than
trying to share them between archs with #ifdef hackery. I agree this
is much cleaner. But it's been polluted slightly by the fact that a
few archs have both little and big endian variants, and the desire to
avoid duplicating the whole arch for just that one variation.
Now, the need to support more variants for some of these (like mips
softfloat) is making the situation even worse.
Using generated headers like I originally proposed would of course
allow us to avoid #ifdef hackery, and even allow us to eliminate what
already exists in endian.h.
Rich
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.
