Re: [v3] default to --disable-long-long, ctype fixes

[Gabriel Dos Reis <gdr at codesourcery dot com>]

george@moberg.com writes:

[...]

| > | (Mr. Dos Reis, does this clarify?)
| > 
| > It does; but largely ignored the concerns I exposed in my previous
| > message.
| 
| The major concern that I gathered from your message is that you do not
| approve of a resource tradeoff where --enable-long-long would get in the
| way of standard features.

This is not the first the long long oddities are showing up.

| ...  I'm wondering _how_much_ of a tradeoff there
| really is, or is everyone getting jumpy because the release is near?

The time it takes not to focuse on getting standard features right.

| After all, I don't want to delay the library for 8 months, or cripple
| it, to get --enable-long-long in there.  However, I wouldn't complain
| about a delay of 3 days or a week.

Given that this is not the first time we have to fight the long long
oddities, on the long run it is not just a question of a week.

The equation is simple: extensions should not break standard
constructs, especially given the limited resource.  

Don't get me wrong.  I'm all for all nifty extensions.  I simply don't
agree with trading standard features for problematic extensions.

| > | I'm not worried about introducing binary incompatibility with the
| > | current CVS.  I'm worried about the inevitable binary incompatibility
| > | between programs and libraries compiled with --disable-long-long and
| > | --enable-long-long versions of libstdc++-v3.
| > 
| > If I understand you correctly, just because the compiler happens to
| > have thousands of options, the library should be built by default by
| > all possible compbinaison of those options.
| 
| No.  This is not what I'm saying.  What I'm saying is that libstdc++-v3
| has to look forward to the real world. 

Certainly, it has to.  But looking forward should not prevent it from
looking for making current and at some extent past programs work
correctly.  In other words, current and legacy codes support are higher
than support for nifty extensions.

[...]

| Also, the most common underlying C library that GCC runs on (glibc)
| supports 64-bits now, with the proper #define. (_ISOC99_SOURCE)

I know that.  There are various things which get in with ISO C99 on
various plateform and which don't agree with the linux-centric view of
the world.  We need to address the problem in such that is acceptable.  
From my point of view, adding extensions after the base is reasonably
right is far more important than focusing on nifty extensions whereas
the basic standard features are yet to be implemented (right).

| What's the lifespan of GCC 3.0 w.r.t. a future release that has
| --enable-long-long as the default?

I don't know.

| ...  How long would users have to wait? 

The time it takes to have reasonable behaviour from the standard
library parts.

| How many troubles with binary incompatibility do you really want to make
| for yourself?

There is no official release with long long support AFAIK.  And adding
a feature is easier than removing it or changing it.


| ...  I thought that the ABI for C++ was supposed to be
| solidified with the release of GCC 3.0.  

So?

[...]

| > It is unreasonable that people who happen to build their programs
| > against non-standard features built in their owns libraries require
| > the standard library to sweep after them.
| 
| 64-bit integers are not such an esoteric feature that we should need to
| hide behind the facade of pedantic standards compliance.

Well, I see.  You seem to believe that supporting long long is just
reduced to shutting up the compiler for every long long support.  That
is wrong.  And the question of having the basics right isn't a
"pedantic standards compliance" issue.  If your position is that
I'm just being picky about "pedantic standards compliance", then I
think there is no need for further communication ont his issue.

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com