Re: Proposal for the 'long long' problems

[Nathan Myers <ncm at nospam dot cantrip dot org>]

On Thu, Nov 01, 2001 at 12:30:08PM -0800, Benjamin Kosnik wrote:
> > IMHO, we should not have any _USE_C99 references in the library at all.
> 
> Reasonable people may differ on this point.

Are you aware of how much incompatible junk is implied by C99?
We have specific needs for support of long long.  Why should
long long support depend on a lot of other unrelated stuff?
On Solarix 8, strtoll is there but the other C99 junk isn't.
You have to jimmy the configure to get long long support on 
Solarix.  That sucks.
 
> > on C99 library features unnecessarily.  In particular, strtoll is 
> > something we would better just slurp into our own code, and not need 
> > to check for or depend on.  (We can also supply our own strtoll that
> > uses the same code underneath.) The implementation would be better
> > for our needs anyhow, and would allow better range checking.
> 
> No.
> 
> We've never agreed on this point.

Are you saying that libstdc++ should always remain a second-class
library, dependent for its most basic needs on whatever C library
happens to be nearby?  If you haven't noticed yet, it's libstdc++
that's shipped with, and built with, the compiler.
 
> Anyway.
> 
> Conceptually, my thinking on this point is that v2 had iostream overloads 
> for long long. The thought is that --enable-long-long could default to on 
> (but able to be toggled off) to gracefully support backwards 
> compatibility. The newer C99 features should have their own flag, since 
> we don't have to worry about what v2 did. 

The C99 features (those that are meaningful in C++ -- or did you want
to have a flag to turn on C99's complex?) should have flags of their own.
The point is, users are not asking for ersatz C99 compatibility (which is
the best we could do), they're interested in particular language features.  

I'm just saying the configure tests should look for what we need for
the particular language feature, and not pretend to detect full C99 
compatibility that we don't need (or want) anyway.  

Nathan Myers
ncm at cantrip dot org