Re: Pascal Calling Convention

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Keith Thompson <kst-u@mib.org> writes:

> Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:
>> 	i = 0;
>> 	someC(i++, i++, i++);

> On my system, it produced (2, 1, 0), but this doesn't mean anything.
> In C, the order of evaluation of function arguments is explicitly
> unspecified.  Furthermore, in this particular case, the multiple
> modifications to the same object without an intervening sequence
> point mean that the behavior of the program is undefined; ...

True, and writing code that can cause undefined behavior is generally a
Bad Thing.  But it doesn't seem like such a bad thing to deliberately
use undefined behavior when trying to figure out what an implementation
is up to "under the hood".  Just don't assume too much -- after all,
the compiler might choose left-to-right order in one case, but not
in another case, for efficiency reasons.

>...it
> could legitimately print "a suffusion of yellow" or cause your
> keyboard to explode.

True, according to the C standard.  But I'm pretty sure that there's
some other standard that will prevent it from blowing up my keyboard.
;-)

By the way, when explaining what "undefined behavior" means, why does
everybody choose a spectacular example, like exploding keyboards,
or seg faults?  I think the worst thing of all is when undefined
behavior does exactly what you want it to do, leaving a latent
bug that will rear its ugly head years later, when you change
some code totally unrelated to the bug, or upgrade your compiler,
or...

>...(C's "undefined behavior" is very much like
> Ada's "erroneous execution" -- and IMHO C chose a better term to
> describe it.)

"very much like"?  Is there any difference at all?  (Other than
the fact that C has more of it, I mean.)

I agree on the terms.  An even better term, IMHO, would be
"unpredictable behavior".

> Furthermore, the order of evaluation of the argument expressions
> isn't *necessarily* related to the order in which the results are
> pushed onto the stack (assuming there even is a stack).

There must be a stack.  But you're right -- parameters might be
passed in registers, or some other way, and there's no reason
to assume that the evaluation order will match the way they're
passed.

- Bob