[PATCH] DEFAULT_SIGNED_BITFIELDS Macro

[craig@jcb-sc.com]

>Craig's argument is that for purity, that gcc should always do things the
>"same" (pure) way.  If I hear you correctly, you're saying that it should
>always conform to the native ABI (otherwise a compatability switch WOULD
>be meaningful).   Do I understand you correctly?

That's indeed the problem, and it isn't trivial to even make decisions
in all cases of conflicts, and there's *substantial* resistance to
even making "obviously right" decisions that'd make things easier for
programmers who want correct results "out of the box" (e.g. the 80-bit
FP-register spill issue on x86).

>If I do, then you're saying that occasionally we have to pay the price of
>having things like differences in semantics for bitfield sign extension,
>and it's the responsibility of the program author that uses bitfields to
>be sure that it's not a problem.

Sometimes we have to accommodate stupid decisions, and that might be one.

(If it's the responsibility of the *programmer* that uses bitfields
to be explicit, then it, theoretically, shouldn't matter what the
compiler defaults to, in which case gcc could happily default to the
same thing across all machines.  Of course, the stupid decision here might
have been the ABI designers thinking it was up to them to "nail down"
an undefined area of the standard, therefore encouraging programmers
on *their* system to not exercise their responsibility of being
explicit, and, worse, therefore writing code that is *wrong* on systems
who ABI designers made the same *type* of stupid decision but with a
different *value*.)

>However, stepping back, there are only two interesting states: native and
>gcc.  99% of the programmers involved (other than compiler writers) don't
>care what "native" means, except that it works locally.  Nor do they care
>what "gcc" means, except that it's fully interchangeable and compatible.

The audience gcc, and GNU generally, targets doesn't care what type
of machine they're using.  They want consistent behavior and, where
feasible, performance out of the vanilla, widely used portable code
they're compiling.

Things like assuming signedness of bitfields, using backslashes in Fortran
character constants, and so on, end up being big problems to the extent
there are comparable existing code bases that differ on the meanings
of those constructs.

I don't know about signedness of bitfields, but the answer for g77
wrt backslashes was "since this is a UNIX f77 replacement, make it
easier for people to just `drop in' g77, so interpret backslashes
as C-style; code coming from non-UNIX systems probably doesn't come
with UNIX-style makefiles, so they'll have to study the new compiler
and decide on what options to pass anyway", even though it's clear,
in hindsight, that C-style backslashes in Fortran was a horrible mistake.

(The new answer is likely to be "disallow backslashes by default", so
there's less risk that code is compiled incorrectly.  But that answer
also requires, to be perceived as even remotely sane by people who
think only in the short term, availability of a program that transforms
code to one of the two defaults, without losing any information such
as commentary.  I knew, when I made the original decision for g77,
that it was not the best, and explained it as such, via email and
via the docs.)

If there's a binary decision, as appears to be the case with bitfield
signedness, then as long as there's at least, say, 65% of existing
code assuming one decision, that's what gcc should go with.  Users
compiling the remaining 35% of the code will just have to use a
command-line option, but, in the end, that's much better than continuing
the confusion over something like this -- as those users will probably
modify their code over time.

But, as AFAICT is so with the g77 backslash problem, it might be the case
that it's more of a 50/50 thing, in which case it'd be fairly punitive
for gcc to make a choice one way or another.  The best tack is probably
to disallow *default* signedness, but since the standard doesn't really
allow that...it's tempting to make it default to whatever programmers
on the local system are used to, and generally pronounce code that
assumes one thing or another as non-portable, *and*, ideally, provide
an automatic conversion tool like the one I hope somebody writes to
"solve" the backslash problem for Fortran code (so we can ship it with
g77 as `g77unslash', or similar).

        tq vm, (burley)