Re: subroutine stack and C machine model

In article <5e332102-a414-48e5-b8d9-> spinoza1111 <> writes:
> On Oct 27, 4:47=A0pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
> wrote:
....
> > Did you read the post where I quote from the standards for several
> > different languages? ALL of which don't specify the order of
> > evaluation of function/procedure arguments.
> >
> > The only one I've found so far is Java.
>
> Then you missed C Sharp:
>
> "Except for the assignment operators and the null coalescing operator,
> all binary operators are left-associative, meaning that operations are
> performed left to right."
>
> "The assignment operators, null coalescing operator and the
> conditional operator (? are right-associative, meaning that
> operations are performed from right to left"

Again you are confusing the order of evaluation of arguments to an operation
and order of evaluation of the operations themselves.
--
dik t. winter, cwi, science park 123, 1098 xg amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

Dik T. Winter

On Oct 28, 7:10*pm, "Dik T. Winter" <Dik.Win...@cwi.nl> wrote:
> In article <5e332102-a414-48e5-b8d9-863337b14...@i12g2000prg.googlegroups..com>spinoza 1111<spinoza1...@yahoo.com> writes:
> *> On Oct 27, 4:47=A0pm, Nick Keighley <nick_keighley_nos...@hotmail.com>*> wrote:
>
> ...
> *> > Did you read the post where I quote from the standards for several
> *> > different languages? ALL of which don't specify the order of
> *> > evaluation of function/procedure arguments.
> *> >
> *> > The only one I've found so far is Java.
> *>
> *> Then you missed C Sharp:
> *>
> *> "Except for the assignment operators and the null coalescing operator,
> *> all binary operators are left-associative, meaning that operations are
> *> performed left to right."
> *>
> *> "The assignment operators, null coalescing operator and the
> *> conditional operator (? are right-associative, meaning that
> *> operations are performed from right to left"
>
> Again you are confusing the order of evaluation of arguments to an operation
> and order of evaluation of the operations themselves.

As it stands, this makes no sense. I understand that the C standard
didn't mandate violating the laws of mathematics, although in the
conduct of vendors we find disturbing echoes of Dijkstra's "CEO of
Mathematica", a suit who wanted to sell mathematical proofs and found
some mathematical laws inconvenient for business.

The original poster above couldn't even express his point
grammatically, so the confusion started there. My point is clear: like
Java and quite unlike C (esp. C99), C Sharp was designed to avoid
bugs. C99 was designed to cause them.

In C99, aliasing and side effects combine with overly permissive
reordering to create a mess.
> --
> dik t. winter, cwi, science park 123, 1098 xg amsterdam, nederland, +31205924131
> home: bovenover 215, 1025 jn *amsterdam, nederland;http://www.cwi.nl/~dik/

spinoza1111

On 28 Oct, 16:06, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On Oct 28, 7:10*pm, "Dik T. Winter" <Dik.Win...@cwi.nl> wrote:
> > In article <5e332102-a414-48e5-b8d9-863337b14...@i12g2000prg.googlegroups.com>spinoza1 111<spinoza1...@yahoo.com>
> > *> On Oct 27, 4:47=A0pm, Nick Keighley <nick_keighley_nos...@hotmail.com>*> wrote:

> > *> > Did you read the post where I quote from the standards for several
> > *> > different languages? ALL of which don't specify the order of
> > *> > evaluation of function/procedure arguments.
> > *> >
> > *> > The only one I've found so far is Java.
> > *>
> > *> Then you missed C Sharp:
> > *>
> > *> "Except for the assignment operators and the null coalescing operator,
> > *> all binary operators are left-associative, meaning that operations are
> > *> performed left to right."

<snip>

> > Again you are confusing the order of evaluation of arguments to an operation
> > and order of evaluation of the operations themselves.

<snip>

> The original poster above couldn't even express his point
> grammatically, so the confusion started there.

was I unclear?

> My point is clear: like
> Java and quite unlike C (esp. C99), C Sharp was designed to avoid
> bugs. C99 was designed to cause them.

as were Pascal, Ada, Scheme and Algol-68

Nick Keighley

On 30 Oct, 05:59, Keith Thompson <ks...@mib.org> wrote:
> Seebs <usenet-nos...@seebs.net> writes:
>
> [...]> Again, no matter how many times you make this stuff up, it ain't what
> > happened. *K&R (197 stated that order of evaluation was not specified
> > by the language, and ISO C (1989) formalized that without altering it,
> > because no one seemed to feel it needed to be altered.
>
> [...]
>
> Going even further back:
>
> <http://cm.bell-labs.com/cm/cs/who/dmr/cman.pdf> is the C Reference
> Manual that came out with 6th Edition Unix in May 1975. *In section 7,
> it says:
>
> * * Otherwise the order of evaluation of expressions is undefined. In
> * * particular the compiler considers itself free to compute
> * * subexpressions in the order it believes most efficient, even if
> * * the subexpressions involve side effects.
>
> <http://cm.bell-labs.com/cm/cs/who/dmr/kbman.html>, dated January 7,
> 1972, describes B, the predecessor of C. *I don't see a general
> statement that the order of evaluation of expressions is undefined,
> but there is a specific statement that, in a function call:
>
> * * The expressions In parentheses are evaluated (in an unspecified
> * * order) to rvalues and assigned to the function's parameters.
>
> <http://www.masswerk.at/algol60/modified_report.htm>, the Modified
> Report on the Algorithmic Language Algol 60, says:
>
> * * The order of evaluation of primaries within an expression is not
> * * defined. If different orders of evaluation would produce different
> * * results, due to the action of side effects of function
> * * designators, then the program is undefined.

darn I tried to find that and failed!

Nick Keighley

On Oct 30, 4:00*pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> In <slrnhekrpf.hd7.usenet-nos...@guild.seebs.net>, Seebs wrote:
> > On 2009-10-30,spinoza1111<spinoza1...@yahoo.com> wrote:
> >> "C: The Complete Nonsense" is the major evidence.
>
> > Hmm. *So you're saying that something I wrote up in maybe an hour or
> > two something like fourteen years ago is clear evidence as to what I
> > have ever learned? *That's interesting.
>
> Actually, it's not as interesting as all that, for much the same
> reason that Doug Hofstadter's aleatoric sentence generator began to
> pall after a time. While he's never actually made that specific
> ignorant claim before, he has made many similarly ignorant claims,
> and after a while a kind of pattern emerges.
>
> <snip>
>
> >> Gee, little
> >> Johnny can't read for the key point, such as "allocate and free
> >> should be isomorphic, in one to one correspondence, and he takes
> >> his rage out on people who can on the Internet. Let's let him take
> >> a class in communications and pass him."
>
> > This would be way, way, cooler if you'd not misused "isomorphic".
>
> My fault, I think. I could be mistaken and I'm not about to check, but
> I seem to recall using the word "isomorphic" myself, long long ago,
> in a discussion with this guy. It is unlikely that I actually
> explained its meaning during first use. (Any subsequent explanations
> would of course be irrelevant, since by then he would already have
> fitted the word and his own special meaning for it into his own
> personal reality.)
>
> <snip>
>
> >> and mandated that pre and post
> >> increment and decrement be applied only to lValues.
>
> > How the **** am I supposed to try to take you seriously
>
> Um, you're not.
>
> > when you
> > demand that the standard "should have" mandated that pre and post
> > increment and
> > decrement be applied only to lvalues? *Why don't you demand that it
> > "should have" specified that execution starts at main(), or that it
> > "should have" included <stdio.h>, or that it "should have" been
> > written in English and distributed in printed form with black text
> > on white pages?
>
> > Hint: *Of course they have to be lvalues. *In fact, they have to be
> > *modifiable* lvalues. *Duh.
>
> If he's bright enough to understand that reply, the ensuing discussion
> could well prove interesting - until the pattern emerges again.

I've confirmed that one modern compiler that claims to be standard wrt
C99 prevents use of ++ with something not an lValue. But in the past,
in other folks' code, I do recall the use of ++ on non-lValues that
compiled. I don't have a copy of K & R (it's in the USA) but perhaps
need to get an electronic copy to check this issue.

I was first exposed to C at a training class at SEI Information
Technology in Chicago and saw a variety of inconsistent
implementations. It wouldn't surprise me if this issue wasn't messed
up by some compilers. If C couldn't get left to right right, it
probably was.

Conditional kudos to Seebach if he helped to legislate the rule in
C99, but it may predate.


>
> --
> Richard Heathfield <http://www.cpax.org.uk>
> Email: -http://www. +rjh@
> "Usenet is a strange place" - dmr 29 July 1999
> Sig line vacant - apply within

spinoza1111

On Oct 30, 1:59*pm, Keith Thompson <ks...@mib.org> wrote:
> Seebs <usenet-nos...@seebs.net> writes:
>
> [...]> Again, no matter how many times you make this stuff up, it ain't what
> > happened. *K&R (197 stated that order of evaluation was not specified
> > by the language, and ISO C (1989) formalized that without altering it,
> > because no one seemed to feel it needed to be altered.
>
> [...]
>
> Going even further back:
>
> <http://cm.bell-labs.com/cm/cs/who/dmr/cman.pdf> is the C Reference
> Manual that came out with 6th Edition Unix in May 1975. *In section 7,
> it says:
>
> * * Otherwise the order of evaluation of expressions is undefined. In
> * * particular the compiler considers itself free to compute
> * * subexpressions in the order it believes most efficient, even if
> * * the subexpressions involve side effects.
>
> <http://cm.bell-labs.com/cm/cs/who/dmr/kbman.html>, dated January 7,
> 1972, describes B, the predecessor of C. *I don't see a general
> statement that the order of evaluation of expressions is undefined,
> but there is a specific statement that, in a function call:
>
> * * The expressions In parentheses are evaluated (in an unspecified
> * * order) to rvalues and assigned to the function's parameters.
>
> <http://www.masswerk.at/algol60/modified_report.htm>, the Modified
> Report on the Algorithmic Language Algol 60, says:
>
> * * The order of evaluation of primaries within an expression is not
> * * defined. If different orders of evaluation would produce different
> * * results, due to the action of side effects of function
> * * designators, then the program is undefined.
>
> --
> Keith Thompson (The_Other_Keith) ks...@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"

Wow, even Algol 60.

The problem is, however, that this was a mistake, because it is not
necessary to mung order of evaluation in order to optimize code. The
optimizer can determine, in an important subset of cases, whether
operations can be reordered. But see Aho/Sethi/Ullman, please, and use
the current edition: the optimizer may make only operations that are
safe, and known to be so. Keithy boy your historical scholarship is
impressive, but it is a record of partial stupidity.

It can reorder a+b where a and b are unaliased lValues, but a good
optimizer would not reorder a(...)+b(...), a+b(...), or a(...)+b,
unless it had full information about the internals of a and b.

Perhaps this is why Algol failed long term. Not knowing how to
optimized, the developers of Algol adopted what Adorno called the
"scientifically ascetic" viewpoint. Whereas languages controlled by
vendors such as early Fortran were more portable as a practical matter
simply because they ran on IBM machines or clones.

spinoza1111

In article <>,
Richard Heathfield <> wrote:

>> But in the
>> past, in other folks' code, I do recall the use of ++ on non-lValues
>> that compiled.

>Broken compiler, if true.

Not necesarily. For example, the useful *((int *)pc)++ was allowed in some
pre-standard compilers and in some post-standard ones as an extension.
That's not because the compilers in question were "broken".

-- Richard
--
Please remember to mention me / in tapes you leave behind.

Richard Tobin

(Richard Tobin) writes:

> In article <>,
> Richard Heathfield <> wrote:
>
>>> But in the
>>> past, in other folks' code, I do recall the use of ++ on non-lValues
>>> that compiled.
>
>>Broken compiler, if true.
>
> Not necesarily. For example, the useful *((int *)pc)++ was allowed in some
> pre-standard compilers and in some post-standard ones as an extension.
> That's not because the compilers in question were "broken".

I doubt that this is a counter-example. The most reasonable way to
permit the above is to extend the meaning of the cast operator so that
it yields an lvalue if it's operand is an lvalue. If memory serves, I
think this has been done at least once. I can't think of any other
way to give the expression a meaning.

--
Ben.

Ben Bacarisse

In article <0.704abb301ea09d7944c6.20091031175011GMT.878wertp >,
Ben Bacarisse <> wrote:

>>>> But in the
>>>> past, in other folks' code, I do recall the use of ++ on non-lValues
>>>> that compiled.

>>>Broken compiler, if true.

>> Not necesarily. For example, the useful *((int *)pc)++ was allowed in some
>> pre-standard compilers and in some post-standard ones as an extension.
>> That's not because the compilers in question were "broken".

>I doubt that this is a counter-example. The most reasonable way to
>permit the above is to extend the meaning of the cast operator so that
>it yields an lvalue if it's operand is an lvalue.

That would make Spinoza's claim meaningless, which it isn't. He
obviously meant that the compiler allowed ++ on operands which were
not lvalues according to the usual (standard) interpretation; how
(if at all) this was rationalised is irrelevant to whether his claim
is true and whether the compilers were broken.

>If memory serves, I think this has been done at least once.

Some drafts of the ANSI standard made cast lvalue pointers "lvalues
for the purpose of additive operations on them".

-- Richard
--
Please remember to mention me / in tapes you leave behind.

Richard Tobin

In article <622a334d-cc8f-4f46-9736->,
spinoza1111 <> wrote:

>> If you're talking about Microsoft's C compiler, I'd be very interested
>> in seeing some evidence to support your claim that it claims
>> conformance with C99, since all indications from MS so far have been
>> to the contrary.

>Well, it doesn't use a random number generator to order a()+b().
>Should it?

Early versions of gcc effectively did. At least, they chose between
different optimisations in a way that was not always consistent between
instances of the same compiler version, and possibly not between
runs of compiler. This was because it used qsort() to choose between
optimisations, and qsort() is not guaranteed to be stable.

This was noticed when gcc itself was used as a SPEC benchmark program,
and unexpected differences were found in the output.

-- Richard
--
Please remember to mention me / in tapes you leave behind.

Richard Tobin