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.