need for flag for incompatible-changes

[Paul Koning]

>>>>> "Per" == Per Bothner <bothner@cygnus.com> writes:

 Per> The problem: We need to continue to make changes to gcc
 Per> exception handling, mangling, etc.  Some of these will be
 Per> incompatible changes. ... So I propose we add a flag to turn on
 Per> compatibility-breaking changes.  The default will be to disable
 Per> the changes - except perhaps for Java, which needs the changes,
 Per> and has no installed base.

A standard way in network protocol design to deal with incompatible
changes is to stick a version number in.  That has a number of
benefits.  For one thing, a version number has more than two values,
unlike a flag.  (So you don't get into trouble when you have to do a
second change a year or two later.)

Another aspect of protocol version number handling is that
implementations generally support at least two versions: the current
one and the one preceding that (if there is one).  As a result, while
the change may be incompatible at the protocol level, it is NOT
imcompatible from the user point of view, because the system adjusts
according to the version number it sees.

I'd suggest an analogous approach.  Is there a "binary format version
number" anywhere?  (There should have been, of course.)  If not,
perhaps one could be created by defining a new global symbol, starting
at 1, the absence of that global implying version 0.

Then you can use this version number to adjust the behavior as needed.

If it has to be per object file (which seems to be the case with
things like exception handler tables) this may still work: the (new)
linker could use the object file version number to determine what
format exception table it contains (and, quite possibly, convert the
old format to the new while linking old object files).

If there are things that cannot be converted by the development tools,
you should *still* have a version number; that way there can be error
messages generated that point out the specific issues.  Without it you
end up with mysterious crashes.  (In the case of exception handling,
it would be particularly nasty: a mysterious crash that happens *only*
if you invoke an exception in the wrong place.)

	paul