Re: GCC not doing the correct thing?
Re: GCC not doing the correct thing?
- Subject: Re: GCC not doing the correct thing?
- From: "Clark S. Cox III" <email@hidden>
- Date: Mon, 11 Nov 2002 09:21:54 -0500
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Saturday, Nov 9, 2002, at 16:35 US/Eastern, Domain Administrators
wrote:
Forgive me for my impertinence, but if the example code were to be
"undefined" by definition, we would all be in a lot of trouble. But
this is not so, and the example given makes the argument all the
easier.
Let's review. We have a macro which I will retype as
#define CUBE(A) ((A) * (A) * (A))
And we have a sample parameter given as
*ptr++
Which supposedly renders the expression undefined.
First, let's substitute as the macro preprocessor has to.
((*ptr++) * (*ptr++) * (*ptr++))
This is so patently simple I am surprised - and shocked - others
don't get it. C uses both binding, precedence, and associativity to
define how expressions are broken down and parsed. For example, we
have both prefix and postfix increment and decrement operators, and
we know what the difference is there. In the expression
*ptr++
We know that ptr is dereferenced before it is incremented, because
of the left to right associativity. We also know that * and ++ are
bound before the multiplication operator. What we get is the
following. Let us say that ptr points to an array in memory such as
the following.
A B C D E F G H I J K L M N
It doesn't really matter how the parser evaluates the expression, as
the substituted parameter is always the same. When the first
expression *ptr++ is evaluated, the parser gets "A" and then
increments the pointer to the next address in the array.
They are not seperate expressions, ((*ptr++) * (*ptr++) * (*ptr++)) is
*one* expression, and it is evaluated (conceptually) as a single unit.
When the next expression is evaluated, the pointer is again
dereferenced, giving "B" before incrementing the pointer again. And
so forth.
This is where your problem comes in, you have no guarantee of that.
Even in the following simple case:
z = x + y;
You have no guarantee that x is evaluated before y. Your only
guarantee is that *both* x and y will be evaluated before the addition
is performed. The compiler is free to compile this to to either of the
following:
fetch x
fetch y
add
store z
or
fetch y
fetch x
add
store z
If none of the subexpressions contains a sequence point (i.e. a
function call, the comma operator, etc), then their relative order of
evaluation is not specified. (i.e. even though they must be evaluated
before the addition is performed, x may be evaluated before y or y may
be evaluated before x).
Dennis Ritchie's original compiler for C, before Steve Johnson's
pccm, was recursive in design, and it is easy to see why he chose
this model. Every expression must be broken down into
sub-expressions, etc., and each of these sub-expressions must be
evaluated first - or according to the above-stated rules.
This is all in the original K/R. We used to have these tables pasted
to our walls - they're that important to know. The thought that
programmers of today not be aware of these very basic rules for
parsing, and think that expressions of the relatively easy CUBE
example given should be "undefined" scares me. The prospect that GCC
or some other compiler get hiccups with something like this shocks
me.
I hate to break it to you, but the original K&R is irrelevant. C has
changed dramatically since then, and wether or not you believe me,
incrementing the same variable more than once before a sequence point
is undefined, the C standard says so, and the C standard is the final
word on the C language.
If you still don't believe me, please read the FAQ for, and/or post to
comp.lang.c, comp.lang.c++ or alt.comp.lang.learn.c-c++, or read the C
standard itself.
- --
http://homepage.mac.com/clarkcox3/
email@hidden
Clark S. Cox, III
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (Darwin)
iEYEARECAAYFAj3PvQcACgkQd6STocYT1xVrCwCgjlf1an4kcGycXrgOBDL/xFfj
6tsAn1VUypOXcFbuoT0Bwoxo+mDE4Mbv
=/ijC
-----END PGP SIGNATURE-----
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.