Re: Pascal Calling Convention

[Keith Thompson <kst-u@mib.org>]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> 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.

Keep in mind that "undefined" behavior doesn't just mean that the code
will do one of N reasonable things.  It means that the compiler is
permitted to *assume*, for the sake of optimization, that no undefined
behavior will occur during the execution of the program.

This particular case is relatively straightforward, but there have
been some serious bugs caused by this kind of thing.  One example
that springs to mind: some code read from uninitialized memory as
a source of entropy for pseudo-random number generation (not the
only source).  That seems like a reasonable thing to do, but the
compiler optimized away the code that did the reading, resulting
in some really bad "random" numbers.

>>...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.
> ;-)

Or from blowing up your rocket?

> 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...

Agreed.

>>...(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.)

There's no actual difference that I'm aware of.  I was just being
cautious.

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

Except that there's no requirement that the behavior must be
unpredictable.

An implementer is free to define the behavior of some construct
whose behavior is not defined by the language standard.  At least
in C, this is a common way to provide extensions.

>> 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.

We've had some lengthy arguments about this over in comp.lang.c.

Yes, an implementation for a language that supports recursion must
have a stack, in sense of a last-in first-out data structure for
activation records.

But the word "stack" is also used to refer to a contiguous chunk
of memory whose "top" is indicated by the address stored in a
"stack pointer".  The stack is grown or shrunk by adding to or
subtracting from the stack pointer (not necessarily respectively).
The last-in first-out "stack" of activation records is implemented
using this kind of hardware stack on almost all implementations of
both C and Ada -- but neither language standard requires that it
must be done this way.  For example, I've heard about IBM mainframe
implementations in which each new activation record is allocated
from something like a heap, so there's no necessary relationship
among the addresses of local variables for successive calls.

I note that the word "stack" doesn't even appear in the C standard,
which manages to describe function calling without using the concept.
Ada refers in passing to stacks for tasks an interrupts; I'm not
sure what kind of requirement that imposes.

I have no doubt that you're aware of all this, but some readers might
interpret your (quite correct) statement that "There must be a stack"
to mean that there must be a contiguous hardware stack, managed via
a stack pointer register, that grows and shrinks linearly in memory.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"