A C showstopper

[Kaz Kylheku]

Kaz Kylheku wrote:
)> That's freedom for the implementation.
)
) Who cares about freedom for the implementation?

Anybody who wants his code optimized properly by the compiler.

C programmers who want aggressive optimizations sometimes switch to
nonportable tricks.

Code should be as safe as possible by default.

Safety can be traded for speed in places in the software where this is
justifiable.

) What is the ratio of users to implementors?

Irrelevant given the above.

) Sanely constraining the evaluation order has the benefit of eliminating
) an entire class of bugs.

Not constraining the evaluation order has the benefit of making code

The evaluation order is greatly constrained already, by the sequential
evaluation of full expressions, and operators like &&.

Yet, compilers perform a great deal of reordering anyway.

Constraints in the abstract order are not barriers to optimization.

Even if the abstract order asserts that A must be evaluated before B,
all it means is that all the observable effects should be as if A
was evaluated before B.

It's up to the optimizer to discover that the effects will be the same
even if A is not evaluated before B.

A compiler which does not do this type of analysis is not commercially
viable.

So for instance, suppose it's better to generate function arguments
right to left. Given a function call like

foo(x, y, z, w);

where these are just non-volatile variables, all distinct, the order can still
be right to left, even if the abstract semantics say left to right!

Evaluating x, then y, has no observable difference versus the opposite order.

a lot more optimizable.
Proof?

Or perhaps you can ask your compiler vendor to add a flag to enforce
strict evaluation order.

Right, following the 90/10 rule. Safety is only needed in 10% of the
code, so only for these ``cold spots'' do we need to turn on safe options.

 

[Herbert Rosenau]

The following code

#include <stdio.H>
int main()
{
int i;
i = 10;
printf("%d %d\n", i++, i++);

invokes undefined behavor making the program completel useless.

We know already that have not a simple idea what C is but quacks
about.


--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!

 

[Herbert Rosenau]

Do not assume that the parameters to printf() (or any function, for that
matter) are being evaluated, in time, from left-to-right. It appears
that on your system that they are being evaluated from right-to-left.

This has been pointed out to you before.

Don't think that a program invoking undefined behavior like this will
produce a bit useful. There is nothing useable independant of the
compiler or OS - undefined behavior is undefined behavior.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!

 

[Herbert Rosenau]

That's nuts. What it means is that different compilers give different
answers, and that means all but one answer is wrong: it also means
that we no longer know (post C99) the right answer.

Nobodfy knows for K&R C, ANSI C 90, ANSI C95, ANSI C99, the possible
upcoming ANSI C 2010 and whatever standard follows that.

This is progress?

To implement the new standard, one would have to do random number
generation.

says the twit that has not understund C at all independant of which
standard that means. You have clearly stated that yyou have not
understund C at its primitevest level.

The real intent of this nonsense was to make as many existing
compilers work without change so that important stakeholders continued
to make money. The public (the programmer: the end user) be damned.

That is what lets go the world around. But now, pleas tell us who is
selling the most used C compiler on the world? Which? See, anybody
knows that this compiler is free in real meaning free as in 'free
beer'. So which big company earns money by sellen GCC? What? There is
none? So you've proven again as twit wo quacks about something he has
not even an idea about he quacks.

Yes, you quacks like a kuck because you quacks like a duck about
things you has not understund and will not understund on you live time
regardless what you ever may try to get it understund on the whole
rest of your live time.

You know as well as I that prior to C99, most compilers went left to
right. It was a defacto standard, and the C99 group should have
certified this. Instead, they chose to please fat cat corporations.

Even when most were true, most does not mean all, not even all free or
alternative to pay for ones.

"Unspecified" is NOT an evaluation.

You proves again that you are unable to understund C.

It would have been better had Microsoft taken over the C language and
effectively standardized it by being the biggest kid on the block, as
it has done with Basic: the best thing that ever happened to Basic, a
Basically crummy language, was Visual Basic, Microsoft's property.
Microsoft should have done the same for C. Rather have one big bad
greedy corporation than a lot of small greedy corporations, since it's
easier to change the big corporation from within and without.

Oh, you proves now that C is not already the only language you knows
nothing about. I can count lots of basic dialects microsoft has
ignored and will ignore for ever, proving that you have not even an
idea about what you are quacking.


--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!

 

[Beej Jorgensen]

In C:

f() + g() + h()

evaluates the arguments in any order, unlike C# which goes
left-to-right.

Erm--I think this is wrong... f() and g() can evaluate in either order,
but h() always evaluates last...?

Reasoning: the operands for + might be evaluated in either order, but
left-to-right associativity causes the expression to be:

(f() + g()) + h()

Or maybe I should just go to sleep now.

-Beej

 

[James Kuyper]

Erm--I think this is wrong... f() and g() can evaluate in either order,
but h() always evaluates last...?

Reasoning: the operands for + might be evaluated in either order, but
left-to-right associativity causes the expression to be:

(f() + g()) + h()

Yes, but keep in mind that even with the parentheses, there are no
constraints on the order in which the function calls are executed. A
perfectly conforming compiler could generate code equivalent to the
following to implement that expression:

(temp1 = h(), temp2 = g(), temp3 = f(), (temp3+temp2)+temp1)

 

[Ben Bacarisse]

Erm--I think this is wrong... f() and g() can evaluate in either order,
but h() always evaluates last...?

Reasoning: the operands for + might be evaluated in either order, but
left-to-right associativity causes the expression to be:
(f() + g()) + h()

I won't repeat what others have said, but it is worth knowing that
precedence and order of evaluation are disconnected in practise, and
not just in theory. Given:

#include <stdio.h>
#include <stdlib.h>

int f(const char *n) { puts(n); return rand(); }

int main(void) { return f("a") + f("b") * f("c"); }

I get, for example:

a
b
c

despite * binding more tightly than +.

 

[Beej Jorgensen]

I won't repeat what others have said, but it is worth knowing that
precedence and order of evaluation are disconnected in practise, and
not just in theory. Given:

This all makes perfect sense at this hour. I think maybe I was just
being tired at 2 AM. What should have clued me in was that I could have
written something incorrect on CLC and not been corrected.

-Beej

 

[Phil Carmody]

Erm--I think this is wrong... f() and g() can evaluate in either order,
but h() always evaluates last...?

Reasoning: the operands for + might be evaluated in either order, but
left-to-right associativity causes the expression to be:

(f() + g()) + h()

You're confusing calling a function and addition.

Or maybe I should just go to sleep now.

Sleep well.

Phil

 

[Tim Rentsch]

Thanks. But it appears to me that the C standard was a corporate
attempt to deprive the C community of its common understanding in C so
that the incompetent employees of vendors wouldn't have to do work and
could indeed be fired. There's too much that is "undefined".

If you think so. In my opinion in C there is much less undefined than in
Fortran, but that is just opinion of course. [...]

My understanding is that it is not just opinion, but
educated and informed opinion.