[RFC] "C" header options

[Benjamin Kosnik]

> This is what we used to have that worked.  It's what KCC, the STLport, and
> Dietmar Kuehl's libraries do.  It's not compliant, but it's awfully hard to
> argue with "it works and everybody else does it" when you're shipping
> production code in a week or so.

Done. This is the approach taken. Thanks for the feedback.

> By the way, builtins can still be inlined, and at -O2 the forwarding
> functions seem to be optimized away so there isn't really any
> performance penalty).

Hmm. We'll have to look at this again in a week or so.

> While I could probably get it to work eventually, it
> just seems somewhat gracile.  I spent a lot of time dealing with subtleties.
> Subtleties aren't good in a general library.  I think the sorts of problems
> I experienced would recur elsewhere on other platforms and multifold with
> cross compilers.

Yeah I'll post details later, so as not to distract people. I did find 
some tweaks with the current library code, where a true std:: compliant 
strategy found some small defects. I'll post these later.

> It's my opinion, and yes, I am slightly biased here, that 3) is the best choice
> for the long run (read 3.1) since it is robust AND it's compliant AND it's
> simple.

The more interesting question is what to do with the staging headers 
patch of yours, Stephen. I've used it for the last couple of days in my 
source tree and I think it is an improvement to what had existed. It 
takes some getting used to, but there are some real advantages to 
treating all the headers as things that must be built.

As soon as I can bootstrap mainline again I'll work on integrating it and 
the "C" header fixes.

-benjamin