Places where ARM C++ isn't upwards compatable from ANSI C:

[Mark S. Miller <vlad!mark>]

Issues are rated from 1 to 5 according to how urgently we need to
think about them.  5 is an urgent issue, 1 is trivia.

This is the first in a series of notes about ARM C++ (C++ as described
in the new wonderful "Annotated Reference Manual").



	Places Where ARM C++ Isn't Upwards Compatable From ANSI C



			Preprocessing

p6:  This program:

	int b = a//* divide by 4 */4;
	-a;

is interpreted by ANSI C as "int b = a/4; -a;", whereas ARM C++
interprets it as: "int b = a -a;".  Yet another reason (IMHO) why they
shouldn't have added "//" to the language.

It turns out that, even if they hadn't added it, a pre-processor for
ARM C++ still needs to be different from one for ANSI C, as ".*",
"->*", and "::" are tokens in ARM C++ but not ANSI C (p7 & p370).  Bet
it'll be a *long* time before we see an claimed-to-be ANSI C and a
claimed-to-be ARM C++ from the same vendor which preprocesses both
correctly.  None of this is an issue for us at the moment, as we are
trying to stay compatable with both of these kinds of preprocessors,
as well as the old string-based Classic C preprocessors.  Also, the
Smalltalk translator never generates "//" comments.  Rating: 2

p379: The discussion of whether __STDC__ may be defined by a proper
ARM C++ preprocessor is confusing.  It is a confusing issue!  I would
argue that __STDC__ may *not* be defined, because a proper ARM C++
cannot be a conforming ANSI C.


			Integral Types


p9,404: In ANSI C, "sizeof('a')" is equal to "sizeof(int)", whereas in
ARM C++ its value is 1.  This results from enabling ARM C++ to
overload on a "char" vs an "int".  Rating: 1

p32: Although ARM C++ is defined as behaving as ANSI C wrt integral
promotion, one is here warned that it'll be awhile before actual ARM
C++ systems do it the ANSI C way instead of the Classic C way.
Rating: 1

p404: Enums are quite different (and non-upwards compatable).  Rating:
1


			Struct Tags

p26: Probably the most significant non-upwards compatability between
ANSI C and ARM C++ is not having a separate name space for tags.  In
particular, the following is legal ANSI C, but was not legal ARM C++:

	struct stat {...};

	extern struct stat stat(int, struct stat *);

Unfortunately, the non-upwards compatablity here apparently proved too
painful, so they've adopted a wierd and hard to understand scoping
convention (described on p26-27 and p166-167) which preserves the new
single name space, but lets more old C programs work (such as the
above).  It's still not upwards compatable from ANSI C, it just
happens to work for more old programs.

I think we should pretend that the new scoping hack doesn't exist.  I
find it quite hard to think about.  I also have no idea how one would
parse the language as defined: The lexer must distinguish between a
type identifier & a non-type identifier (which it would otherwise be
able to do via a feedback channel from the parser).

This is not an issue in our own C++ code, but is an issue for our
parser based tools (e.g. formic).  Formic currently ignores the new
scoping hack (as I advocated).  Rating: 3


			Types

p166 (and scattered elsewhere): ARM C++ relies on name equivalence of
types, whereas ANSI C sometimes relies on structural equivalence.
Rating: 1


			Initialization

p153: 'char cv[4] = "asdf";' is legal ANSI C but an error in ARM C++
(no room for trailing 0).  Rating: 1


			Functions

p404: In C, "int f()" == "int f(...)", whereas in ARM C++ "int f()" ==
"int f(void)".  ANSI C deems "int f()" obsolescent.  Whenever we
encounter the first form in a C header file we should fix it.  Rating:
2


			Identifiers

p6,404: This isn't a non-upwards compatability between ARM C++ and
ANSI C, but an issue in the ARM C++ definition which makes it
impossible to write a cfront which produces a conforming ANSI C
program: ARM C++ imposes no limits on the length of identifiers.
Therefore a correct cfront for ARM C++ probably requires a C compiler
with a similar ability.  This additional ability is allowed but not
required in ANSI C.  One suspects there will be many claimed-to-be ARM
C++s which don't meet this spec.  Rating: 1


	Incompatabilities Section (Section 18.2, p403-404)

Please read this section of the ARM.  I've only commented on those for
which I have something additional to say, or which weren't mentioned
in this section.  Rating: 2


There are many incompatabilities between ARM C++ and Classic C.  These
are well documented in the book, and I won't be commenting on them.
More interesting are differences between ARM C++ and C++ as we've
thought it was (C++ as of cfront 2.0).  Coming soon to a mail message
near you.