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

[George Talbot <george at moberg dot com>]

On 20 Dec 2000, Gabriel Dos Reis wrote:

[...]

> | 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.

_That_ I was not aware of.  Do you expect many more?


[...]

> 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.

OK.  I was under the impression that long long support was "just about
done" with the exception of this header thing.



> 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 can understand your point.  I think the basic disconnect here might be
that, in my view, 64-bit integers are a basic, and very important, 
language feature, and that you and Mr. Kosnik feel that they are a, as you
put it, "nifty extension".

It's that assessment that I'm trying to change.  ;^)  The issue to me is
not "why don't you support this nifty extention?"

The issue is "why are you breaking support for this basic, and rather
crucial, data type that's already supported by the compiler and the other
standard libraries?"





> | > | 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.

Point well taken.  However, how much does pre-defining _ISOC99_SOURCE in
C++ programs really cause a problem?  Especially considering people with
existing C++ programs that upgrade to GCC 3.0 will have to do pretty
extensive source changes to add things such as the std:: namespace anyway.

At the same time, to harp endlessly and most irritatingly upon the
incompatibility issue once more:

The Standard C++ Library isn't like other libraries in that when a C++
program uses it the program is tied in a much more intimate way to a
particular version of the library, because of the templates and the binary
representation of class data (vtables, fields, etc) that gets fixed at
compile time.  If getting rid of --enable-long-long just changed some
#define's in a header file, I could live with it.  Unfortunately, it
changes the interface to the binary portion of the library in such a way
that (and I'm pretty sure about this) each C++ library that a program
links against must also be compiled with the same --enable-long-long
setting.

This means that if I need to write a C++ program that supports 64-bit
integers via --enable-long-long in libstdc++, and it uses, say, Qt
because it's got a KDE graphical front end, then when I hand out source
to the program, I not only must require that people receiving the source
compile my program, they must also recompile libstdc++, Qt, and possibly
KDE itself.

In any sort of practical sense, there's no way in hell anyone will want to
be bothered with such a daunting task.  Disabling 64-bit integers now will
essentially kill off any practical use of the feature, except for 
closed-source proprietary programs where the vendor can either re-build
their entire distribution with --enable-long-long turned on (I.E. embedded
system people or others who wholly control the environment where the
program runs), or they ship a huge statically-linked binary.

Saying, essentially, that "users who need --enable-long-long can turn it
on manually" is not a practical, viable solution.


> [...]
> 
> | 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).

So, let me see if I understand this correctly:

	1)	Defining _ISOC99_SOURCE for C++ compiles may be
		(or is) problematic.
	2)	It's not acceptable to only solve this for Linux,
		but that you'd want to solve it for all platforms.
	3)	It's getting in the way of standard features.

I would argue that if the issue can be easily solved on glibc platforms,
then let's solve it for those platforms, disable the feature for other
platforms, disable the feature where it doesn't work, and let the
glibc/gcc-based platforms take the lead here.

To me, I guess it really depends upon how much of a problem pre-defining
_ISOC99_SOURCE in C++ files for glibc platforms would cause.  Do you or
anyone else have a good idea?  I do not, as I'm not a C99 expert.

If this approach (pre-defining _ISOC99_SOURCE) doesn't cause too many
problems, then would this make it acceptable to make --enable-long-long
the default again?


[...]

> | > 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.

Let me apologize to you right now, as I see that I have offended
you.  I was frustrated because I felt that "this is not in the
standard" was the reply to most of the arguments I've raised in favor of
64-bit integers.  I wasn't intending to argue against implementing basic
features.  I'll endeavor to learn to phrase things in a less
confrontational way.

--
George T. Talbot
<george at moberg dot com>