mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@aerifal.cx>
To: musl@lists.openwall.com
Subject: Re: Design idea for subarchs/abivariants
Date: Wed, 28 Nov 2012 20:21:08 -0500	[thread overview]
Message-ID: <20121129012107.GV20323@brightrain.aerifal.cx> (raw)
In-Reply-To: <20121129002251.GA13394@intma.in>

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


  reply	other threads:[~2012-11-29  1:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-28 19:26 Rich Felker
2012-11-28 20:03 ` Isaac Dunham
2012-11-28 21:50   ` Szabolcs Nagy
2012-11-28 23:57   ` Rich Felker
2012-11-28 20:26 ` John Spencer
2012-11-28 22:38 ` Szabolcs Nagy
2012-11-29  0:10   ` Rich Felker
2012-11-29  0:22     ` Kurt H Maier
2012-11-29  1:21       ` Rich Felker [this message]
2012-11-29  8:03       ` Szabolcs Nagy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121129012107.GV20323@brightrain.aerifal.cx \
    --to=dalias@aerifal.cx \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).