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

[george@moberg.com]

Benjamin Kosnik wrote:
> 
> > Please reconsider this.  Would it be possible to put something in one of
> > the libstdc++ headers like this:
> >
> > #ifdef _STDLIB_H
> > #ifndef _GNU_SOURCE
> > #error "Must add -D_GNU_SOURCE, or suitable system-dependent macro, to
> > compile this program."
> > #endif
> > #endif
> 
> No. First of all, this is linux-centric, and all linux bits have to go in
> os_defines.h.

I was just "tossing something out there".  I was just suggesting a
crusty hack.  ;^)  While the implementation I suggest may be a piece of
^*&*(&^, the idea behind putting some error or warning in the header
file might in fact be sound.

Sorry if I wasn't clear before.  Maybe there's a nicer way to do this,
or maybe the glibc people can help out.  If there's problems with the C
headers, then maybe those guys need to address 'em.

I realize that this doesn't help non-GNU people much, but I think it
might be worth it to at least see what the glibc people think about
helping with this issue.  Would they accept a patch that would make your
life easier?

I realize that, to quote Gabriel Dos Reis, "The World is not GNU
Based.", but isn't this library a part of the GNU Compiler Collection? 
;^)




> Second of all, long long is not part of the standard. Sorry.
> 
> > Turning off --enable-long-long is a really serious hardship for those
> > who need it on.  It means we have to recompile libstdc++-v3, right?  Or
> > since the compiler's now merged in, we would have to recompile both,
> > right?  I would seriously prefer to use the binaries as shipped with the
> > distribution(s), rather than having to recompile all this.
> 
> Keeping it on by default is a serious hardship for those who don't care
> or want a standards compliant library without gobbly gook. See the
> original post.

I re-read the original post, and about all I can see is that anyone who
_uses_ long long with libstdc++ needs to do something like
-D_GNU_SOURCE.  Unless I'm incorrect, someone who _doesn't_ use long
long wouldn't be affected, right?

Also, if glibc can be fixed to help fix this problem, then it all goes
away, right?  I wouldn't mind too much if, on platforms that have this
problem, I have to do --enable-long-long manually.  However, on a GNU
platform, glibc should be fixed and this problem shouldn't exist.




> People who want it on can still use it, they just have to configure for
> it and plan on using it. I don't see evidence that this is a real hardship.
> 
> > After all, long long will be required eventually.
> 
> At that point, we'll reconsider. See the "at this point" part of the
> original announcement.

Mr. Kosnik, I realize that you're probably frustrated with trying to
solve this problem, and I empathize with you.  However, apart from some
abstract idea of strict standards compliance, I humbly beg you to think
about having the library support the basic data types of the compiler.

After all, I'm using long long and libstc++-v3 now.  ;^)  Seriously,
with all the 64-bit processors coming out, how long do you really think
it's going to be before people really start having trouble because of
this?  Even with 32-bit processors, anyone who cares about file sizes
>1GB or using microseconds for timestamps will be bitten by this.

Consider that I'm a user of this library now, and I'm complaining, and
the library hasn't even shipped yet.  This might be a good hint that
this issue will pop up really fast when the library does ship.

As to binary incompatibility, what I was grousing about, which I now
realize that I didn't explain well, is that when GCC 3.0 ships, you will
create instant binary incompatibility problems for end users that use
long long.  I'm not worried about binary incompatibility with the
current CVS.  I'm thinking a little longer term than that.

The scenario is this:

	User A uses long long and recompiles his libstdc++
	with --enable-long-long on his RedHat 9.0 machine.

	Program runs great on User A's machine.

	User A gives program to User B, who also has
	RedHat 9.0, and it segfaults because RedHat 9.0's
	libstdc++ hasn't been compiled with
	--enable-long-long.

	User A re-links the program statically with
	libstdc++ and freaks out when the binary grows by 6MB.

	User B gets mad the new huge version still crashes.

	User A then freaks out again when it's discovered
	that the program uses library Q, which is 3MB and
	linked against --disable-long-long libstdc++-v3, and
	must be recompiled and statically linked against the
	program increasing its binary by another 3MB.

	Shame User A's binary was 100k originally and is now
	9.1MB.  Shame User A still has a 56k modem.  ;^)

	(Not to be too much of a jerk, but you get the idea,
	right?)

(Mr. Dos Reis, does this clarify?)

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.

Does this change mean that someone who has a C++ program that uses
libstdc++-v3 --enable-long-long will have to recompile _any_ C++ library
that uses libstdc++-v3?  I'm not sure that it will actually be possible
to distribute a program that uses long long and libstdc++-v3 without
having the default be --enable-long-long.

Also, someone who uses long long with libstdc++-v3 can't give source to
others without making _them_ recompile their libstdc++-v3, and not
everyone will necessarily be equipped to do such a recompilation. 
Essentially disabling long long now will keep people from using it
_at_all_ until it gets in the standard, and another rev of libstdc++-v3
is worked on and issued.

<SmartassMode>
Also, since Java has a working 64-bit integer, C++ oughta be at least as
good, right? ;^)
</SmartassMode>

Considering that I bitched about a more trivial issue (hash_map with C++
string class as a key), I hope you don't dismiss my response to this
issue out of hand.  hash_map I could solve with a couple of lines in a
header file, so it's OK.  This issue, on the other hand, has much more
severe ramifications, both for me and others.
--
George T. Talbot
<george at moberg dot com>