Re: [PATCH] DEFAULT_SIGNED_BITFIELDS Macro

[craig at jcb-sc dot com]

>It would be nice if there were a straightforward answer, but there
>simply can't be: either the user that wants native compatability or
>the user that wants gcc compatability will "lose" in some sense,
>and both those classes of users are our "customers", and we have to
>serve them both.

Generally speaking, code that depends on native facilities versus
widely-implemented assumption is simply not portable.  Having a
compiler default to accommodating those particular facilities merely
extends an illusion that the code is a bit more portable than it
really is, when all that's happening is that the *compiler* is less
portable than *it* could be.

OTOH, widely portable code *can* be compiled by any compiler that is,
itself, designed to be portable.

If you have gcc default to choosing native assumptions over the
widely-implemented assumptions...

...then gcc is no longer a portable compiler in the general sense,
and that *widely portable* code I referred to above is code that
gcc won't, itself, compile on some systems.

It is a painful issue, but, in the end, except possibly for a *very*
few native systems, the amount of code that depends on the assumptions
of those native systems is miniscule compared to the amount of code
out there that *could* port quite easily to those systems if gcc simply
worked "out of the box" on them.

But gcc won't do that if it defaults to native settings.

In that sense, the maintainers of the "native" code have to get used
to the idea that it's *their* lack of portable code that requires them
to take special care when using a new compiler.  This is reasonable
even when the "new compiler" is simply a new version of gcc, which has
been trumpeted from day one, IIRC, as a "portable compiler" -- which
means quite a bit more than "a compiler that happens to be portable
to many machines", in particular, it means "a compiler that provides
a portable dialect of [C/C++/Fortran]".

Anytime gcc fails to provide that portable dialect across all its
systems, it's reasonable for that to be considered a bug that needs
fixing, leaving it to the (old) users of that system, with the
non-portable code, to cope.  That's true even where we've willingly
"swallowed" past problems in this area -- as we learn how bad those
decisions ended up being, we can, and almost certainly must, break
with "tradition" and fix gcc so it *improves* as a portable compiler,
rather than stagnating or, as it will tend to do if it isn't
improving, degrading.

(I'm not even getting into issues like the fact that, the more
consistent the code-generation strategies, even the "visible"
stuff, are across *all* systems by default, the more likely it
is that bugs are quickly found and fixed, from the code to the
documentation to the collective experience of the user base.
Those are *huge* factors arguing to complete cross-platform
compatibility as well, though they're hard to put a "value" on.)

In an extreme case, such as a system so obscure that nobody would ever
want to port any of the billions of lines of existing code to it,
but millions of lines of code already exist making native assumptions,
it's *possible* that it's reasonable to have gcc default to that system's
native assumptions.

However, I have yet to see anyone offer a good justification for why
*gcc* (g++ g77 etc.) needs to be the *command* that so defaults.

Instead, the commands 99.95% of the compiler-using world uses to compile
widely portable code should Just Work as they do on all those other
systems for the same code.  That's the community that uses
"gcc foo.c" in their scripts to compile C code, and expects it to
work.  The users of the native system, those users with non-portable
code, have far less work to do to cope with gcc not behaving exactly
as their old compiler expected (even if it was an earlier version of gcc),
compared to the greater audience (the needs of the many outweighing
the needs of the few, so to speak; especially given the fact that it's
the *efforts* of the many that makes gcc available, *at all*, to those
few).

Then, if someone wants special native defaults, they can write a script
that invokes gcc with the proper options, the necessary preprocessing,
whatever, and call it `oldsys-gcc' or something like that.

Bending gcc so it defaults to accommodating the whims of whatever
system it happens to run on makes it much less useful to the computing
community as a whole.  It also makes it harder to maintain, especially
when the time comes for rewrites necessary for it to evolve.

        tq vm, (burley)

P.S. Anyone wanting to see a really sad example of this in g77 should
see "Backslashes in Constants" in the g77 docs.  I didn't like having
to make that decision the way I did, but it was one of only two
possible correct decisions, and the other possible one (rejecting
backslashes outright by default) is what I'm probably going to have
g77 default to for gcc 3.0 aka g77 0.6.  (Because, as of that rewrite,
I can provide the programmer fine-grained, documented control over
how backslashes are to be interpreted.  And maybe get volunteers to
write program that transforms old Fortran code needing backslashes to
use the new constructs.)

P.P.S. Anyone who disagrees that the importance of the user community
as a whole trumps the "installed base" of a particular type of
system, especially where it concerns how a program designed to be
widely portable is to behave, deserves to be blamed for the horrible
leading-tab bug in the Makefile format, which has probably been
single-handedly responsible for hundreds of thousands of lost
programmer-hours since the bug was willingly preserved for
"compatibility".  After all, it's the same mind-set -- "don't make it
right, make it convenient for *me* and *my* users".

Difference is, now we have all the data we need to stop making mistakes
like that -- a mistake made, IIRC, back in the mid-'70s.

But I suppose there are so many hot young programmers coming up through
the ranks that think it's *cool* that Makefiles require invisible
tabs as distinct from spaces, they're only too willing to create even
more bugs like this.  It's just a question of how willing the gcc
developers (among others) are to go along.  Sometimes I think it's
a lost cause to try and defend against this constant attack on
attempts to create solid, well-designed, clean software, especially
given the (generally justifiable) attention Linux gets, and the
resulting pressures on gcc to reliably guess at what that particular
chunk of code really means by its use of standard-breaking C constructs
(in combination with assembler code and all sorts of extensions to C
unfortunately offered by gcc).

P.P.S. This is something like the tenth time I've written an email like
this to this list.  If somebody is willing to put this or similar sentiments
up as a FAQ on this issue (and related ones), feel free to use
materials from my emails on this topic to this list.  I'm willing to
offer some editorial assistance, but can't take on the task myself
right now.