[PATCH] DEFAULT_SIGNED_BITFIELDS Macro

[Donn Terry]

Horst von Brand wrote:
> 
> Donn Terry <donn@verinet.com> said:
> 
> [...]
> 
> > 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.
> 
> And I'd say that the "native compatibility" should be the responsibility
> (and the work!) for the people who use that specific port. Note that this
> could very well change from one "native" compiler to another, from one OS
> release to the next, ...
> 
> Also, to create, maintain, verify correctness, and update as needed the
> respective flags and the corresponding code (there probably are many of
> them!) is a _huge_ amount of work, work that impacts everyone involved with
> the compiler. This can not be taken lightly!

That's exactly the point: the detailed semantics of "native" varies with every
ABI (at least).  There's probably a finite set of choices, but I know
for a fact that gcc doesn't cover them all (as I have a patch pending for
MS packed field layout, which is different than anything else I know of).
However, the compiler porter will likely know what the particular combination
of options needed for a specific port would be, and can set and maintain them.
This is real work (and sometimes hard, as often such decision are not consciously
made and thus not documented).  However, in general, given system vendors'
need for backwards compatability, they don't change very rapidly, if at all.

The question is *who* does the work.  Each programmer writing an application
that needs to match the non-default mode (whichever it is), or the porter,
once (and probably better).

If, as Jeff appears to say, the goal is ABI compatability, this is not additional
work.  If the goal is a single interpretation, this *is* new work, except that
the porter is certainly going to get pressure from his immediate customers
(the users of HIS version of the compiler) to provide ABI compatability anyway,
so the work will often happen.  Whether that's reflected as a bunch of
fine grained switches or one "big" switch (as well as the fine-grained ones)
is really the choice we're facing: either way, I claim the work of figuring
out which options (and implementing them if necessary) provide "native" mode
will occur.

Yes, it's up to the porter of gcc to work that out.

The issue is for the application writer: how does he assure that he gets what
he expects: lots of fine grained control, or something that provides a useful
abstraction 99% of the time and works across (hopefully) all ports.
(I don't think the application writer that knows that he wants "native"
cares what that means, simply that it works.)

If we think about this issue in its nastiest form, binary file interchange
rather than just "system call" ABI, I think it becomes clearer: files written
with the native tools can only be read/written from a gcc that supports
native mode.  Files written in "gcc" mode can only be read/written from a
gcc that supports "gcc" mode.  Short of completely non-portable "hand packing"
code, native mode is unavoidable in this situation, because there WILL be
native binary files.  I don't think we want to give up either choice.
But, to repeat myself, and you, it is up to the porter to make the proper
choices as to what "native" means, and if the set of gcc choices doesn't
cover the specific case, to create it (and hopefully submit it so the next
poor porter doesn't have to re-invent THAT wheel).

Donn
-- 

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================