Re: GCC not doing the correct thing?

FROM : Clark S. Cox III
DATE : Mon Nov 11 15:21:54 2002

-----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_removed>
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_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.