Re: subroutine stack and C machine model

In <0e811876-0aff-427d-93cb-263bd3bd717d@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
spinoza1111 wrote:

<snip>

Unspecified evaluation order was a "hallmark" of older programming
languages because it was thought to be something appropriately
determined by the programmers of compilers...

Earlier on in this debate, you thought that unspecified evaluation
order was something introduced for the first time by C99. So I'm not
inclined to ascribe any weight to your pseudohistorical diatribes on
the subject.

<snip>

Microsoft, which is powerful enough to enforce defacto standards
over and above conformance to multivendor standards, spares itself
trouble by declaring in MSDN that the order is NOT
non-deterministic:

Microsoft's documentation is notoriously poor, but nobody ever said
that the order is non-deterministic. It /is/ determined - by each
implementor individually, according to his or her platform
constraints and opportunities.

"[...] Where
several operators appear together, they have equal precedence and
are evaluated according to their associativity."

Not true. For exasmple, in the test I conducted here just now, the MS
compiler evaluated A() * B() in accordance with associativity, but
A() ? B() : 0 the "wrong" way round wrt associativity.

C's nondeterminacy is recognized as a bug and not a feature in
academia.

Can you demonstrate this? Let's find out.

This journal article recognizes "sequence points" as a C
idiom,

C++ too, of course.

and idioms are usually signs of a language mistake

So you claim. The journal you quote does not claim that.

<snip>

understand compilers without having to read Aho et al. As such he
diminished the power of an autistic geek elite

Any stick to beat him with, eh? Too academic, not academic enough,
good at mathematics (or "autistic", as you appear to prefer),
uneducated and yet elitist... Emerson redoubled in spades.

Yes, any stick that's appropriate.

He's right, you're wrong, and there is no appropriate stick.

To insist on irrevelancy may "sound" academic,

No, it sounds like you.

<snip>

OK, did you add that rule to C99, or is it in the standard?

Firstly, C99 *is* the (de jure) C Standard. Secondly, it's a
standard to which Microsoft's compiler does not conform. The ++
operator requires an operand that is a modifiable lvalue, not only
in C99 but also in C89 and indeed in C compilers that pre-date C89.

Microsoft enforces this rule.

As it must, to be C89-conforming.

So in what way is Microsoft nonconformant?

Microsoft has never attempted to conform to C99. Note that C89 is not
the same thing as C99. Note further that an implementation may choose
to conform to one standard but not the other. Note further that the
rule in question applies to both standards.

In not being non-deterministic as regards expression evaluation?

No. I don't know where you got this non-deterministic nonsense from.
Evaluation order is an implementation decision. The implementor
determines evaluation order. Therefore, evaluation order is
determined, and therefore it cannot be non-deterministic.

Note that in fact few or no compilers, Microsoft or other, actually
CONFORM to the nondeterminacy called for in the standard in a()+b().

The Standard makes no such call.

This shows the near-criminal misuse of standardization,

No, it shows that you're an ignorant man who grasps at the shadows of
straws.

for making nondeterminancy a standard was not a favor to coders,

Just as well they didn't do it then.

nor did it
improve, or for that matter even "standardise" C semantics.

Of course not, since the Standard never required non-determinacy. What
the Standard says is that implementors get to choose evaluation
order. That doesn't mean they are required to install a radioactive
source in every computer to get some good entropy going.

Quite the reverse, for non-determinacy is by definition not
standard!

And was not standardised.

A useless non-determinacy was made the standard

No, it wasn't.

It is autistic on your part

Any stick to beat him with.

Quit whining.

I'm not whining. I'm just pointing out instances where you try to play
the man rather than the ball, and fail miserably.

I have a lot of sticks because my case sticks, mate.

"Case" is not the word I would have used.

to try to use errors in detail to make a case at the level I'm
discussing.

In programming, the details *matter*.

To nasty little clerks.

To you, the details don't matter, which is why you screw up so much.

The rest of us automate the detail work.

Writing correct Usenet articles is detail work. If you have not
automated it, you show yourself to be in error. And if you have
automated it (which is entirely possible, given the appalling
irrelevancy of your arguments), you have a lot of debugging to do.

My errors are correctable;

Then please get on with it.

That's bullshit and you know it.

Um, no it isn't. You have made many errors in this article alone (i.e.
the one to which I am replying).

You've learned about most of my errors

I find that very hard to believe.

when I've admitted them and/or a guy like Bacarisse has found
them.

Or me, or Chris, or Flash, or Seebs, or just about anyone really. It's
like hand-grenading fish in a barrel.

I've corrected them, most recently the grammar error in the
parser discussion, where tonight I've posted C Sharp code to parse
using the corrected grammar.

See, there you have another error - this is comp.lang.c, where we
discuss C, not C#.

<snip>

Ben is right to correct me most of the time:

Wrong. *Any* error of yours that Ben corrects, he is right to correct.

Peter some of the time.

Wrong. *Any* error of yours that Peter Seebach corrects, he is right
to correct.

You, almost never,

Wrong. *Any* error of yours that I correct, I am right to correct.

but sometimes, such as when you complImented me
on my knowledge of a simple word pair. Keep improving.

That article really did go completely over your head, didn't it? I
thought it would just skim your hat, but it seems I was wrong.

in what I consider an important cause. I shall be right on the
morrow, whereas you will still be a stupid little twerp who
thinks that free(NULL) is a counterexample to the need to balance
free() with allocation and that C needs to be semirandom because
that allows it to be optimized (the reverse is true: C is more
difficult to optimize than more deterministic languages).

Presumably the difficulty in optimising C explains why it wipes the
performance floor with other languages.

Wrong answers are still wrong answers when arrived at fast.

True enough, but nobody has argued that providing wrong answers is
acceptable.

What you imply may be true: C may be more resistant to optimization.

That is not what I said and not what I implied. What I implied was
that C is particularly *easy* to optimise.

But this means that some idiot's opinion trumps the collective
wisdom of automated optimization.

No, it means that you misunderstood my point (in fact, you seem to
have got it exactly backwards).

<snip>

I think that the design of C is so poor that learning it destroys
other parts of the brain.

Take it to a medical newsgroup. Or a psychiatry newsgroup.

<snip>

But, in programming, we know how to deal with errors.

Well, we do. It is not evident that you are particularly skilled in
that area. Acknowledging errors is a vital precursor to dealing
with them, and you're weak in that area.

SO IS DECENCY AND RESPECT,

If you mean you're weak in decency and respect, I have to accept that,
for a change, you're right. But I suspect you don't mean that, in
which case you're wrong.

and not jumping to unwarranted conclusions

Which unwarranted conclusion? Do you mean MI5? Antisemitism? Fascism?
Learning disorders? Time-machine-enabled "competition"-trashing?

about what Schildt does or does not know based on his
attempt to be clear...

He's perfectly clear. Unfortunately, all too often, he's perfectly
wrong.

especially when you concede that the attempt
is successful.

No, it is riddled with errors, and he makes no effort to deal with
that problem.

People won't admit errors in an environment dominated
by autistic twerps

Excuse me, but are you the autistic twerp to whom you are referring? I
ask only for information. I assume you mean you, since you're the
only twerp in this discussion, but I must admit I didn't know you
claimed to be good at maths.

who globally question their competence based on
one data point.

Are we back on Schildt now? *LOTS* of data points.

You made a FOOL out of yourself pulling that shit on me in 2003

Well, you can think so if you like, but hoping won't make it so.

when you so generalized based on one data point,

Alas, there were a great many data points.

that
being my use, for readability, of repeated limit evaluation for. You
later were embarassed when people brought your attention to my book.

Why would I be embarrassed by a book? Badly-written books are ten a
penny. I assume your book /is/ badly-written? If so, it is you who
should be embarrassed by it. And if not - if you can actually write
well - why not write well in Usenet?

And one major
way is a free and open discussion undominated by autistic twerps.

Using "autistic" as a pejorative is just pathetic. As for twerps,
well, twerp is as twerp does. Seebs's articles do not seem to me to
be particularly twerpoid.

In view of the foul abuse which you have enabled

Um, no, you're the one with the chicken-coop mouth.

from the zanies
here, "autistic twerp" is both documented and defensible.

Well, then I have to conclude that you mean you.

<snip>

At least you have the good sense not to learn [C] from Schildt
books. So there's some hope for you yet. (Unfortunately, Schildt is
by no means the only C author who doesn't know C very well, so
beware.)

Get it straight. For the same reason that clarity implies
understandability, and understandability implies truth,

What rubbish! It is easy to understand, for example, that C mandates
that the evaluation of function argument expressions proceeds from
left to right - but it's complete nonsense nonetheless.

the
knowledge of mistakes coupled with the belief that mistakes make for
a more "efficient" language should NOT be called knowledge at all,
just as a lawyer in Bleak House who knows Jarndyce and nothing else
does not know the law. C's nondeterminacy was a mistake.

Your mistake.

In fact, the programmer who codes a()+b() is smarter than the twerp
of a compiler developer who inverts the order for shits and giggles.

Since no order has been specified, "inverts the order" isn't actually
meaningful.

This is because the twerp, when said twerp decides to get gay and

I didn't realise you were homosexual. Or do you just mean "happy and
carefree"?

<nonsense snipped>

I admit technical errors,

Eventually, and after much stupid stalling, you do sometimes admit
technical errors.

but what you call "errors" are mostly matters of opinion,

No, mostly I leave matters of opinion alone, or mark them as such.

and you're one of those pub ranters who must always be right.

Well, I'm not a pub ranter, so you're wrong there. And yes, OF COURSE
I must always be right. If I'm wrong, I WANT TO KNOW ABOUT IT! You,
on the other hand, would prefer denial.

What's worse: you're a sober pub ranter.

Well, I'm sober, yes. But I'm not a pub ranter.

<nonsense snipped>

Hey Seebs, if you're reading, I offer a suggestion - you could
promise to remove any item on the CTCN page that you can find dealt
with properly on Schildt's errata page for the book. Would that be
a decent compromise?

No.

Why on earth not?

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

Relevant Pages

  • Re: subroutine stack and C machine model
    ... old-fashioned compilers that evaluated left to right. ... was that the C99 standard should have decided on an order because ... evaluation order, despite using it on several large projects. ...
    (comp.lang.c)
  • Re: x=(x=5,11)
    ... While the comma sequence point does in fact guarantee this, ... As I said in the portion you chose to snip, ... I agree that the standard is ambiguous about this (which is where we ... sequence points is to insure that the evaluation is complete. ...
    (comp.lang.c)
  • Re: x=(x=5,11)
    ... While the comma sequence point does in fact guarantee this, ... As I said in the portion you chose to snip, ... sequence points is to insure that the evaluation is complete. ... What we are really interested in is whether the standard allows the ...
    (comp.lang.c)
  • Re: Is microprocessor an integrated circuit???
    ... <severe snip mode on> ... standard clearly defining a byte as not necessarily being eight bits. ... > what does ibm have to do with the official ... THe processor is not a microprocessor. ...
    (sci.electronics.design)
  • Re: subroutine stack and C machine model
    ... The Standard ... who's read Schildt, not the Standard. ... Most compilers have left to right evaluation as it happens. ...
    (comp.lang.c)