Evaluation order of function parameters

[Mark McIntyre]

What do you mean by "stable"? Obviously the exact same copy of the
compiler is likely to produce the same code tomorrow as today.

Even this isn't guaranteed. Consider hardware that has parallel
execution pipelines, and today, only one is available but tomorrow,
two are. You could easily get two different sets of results.

For example, trivial changes to the surrounding code might change the
registers available,

Or, more likely, other applications running on the same machine..

 

[Mark McIntyre]

On Thu, 24 Nov 2005 08:55:04 GMT, in comp.lang.c ,

The OS' job is, amongst others, to prevent the
bullet from reaching flesh unless you have Write permission on your own
extremities.

A new film title: "The umask of Zorro"

gd&r

 

[Nick Keighley]

I don't see why you (and other so-called "regulars") bother to post these
<expletive> answers.

it isn't nonesense. It's the absolute truth. I've seen quite radical
changes in behaviour
between different versions of the same compiler. I'm just curious about
why *you*
want to promulgate falsehoods.

Well, actually, I do. You know perfectly well that to
the OP, they (your answers) are <expletive>, but you do it to impress your
"peers" (other so-called "regulars").

It seems to me that a simple, short, crisp:

Not portable. Can't discuss it here. Blah, blah, blah.

is a lot more appropriate - much more likely to help the OP - than is your
long discourse on why it is not covered by the standard.

actually it *is* covered by the standard. The standard says the
behaviour is
undefined.

For crying out
loud, the OP has already allowed as how it is non-standard; he doesn't need
to be told that (again & again). Again, a simple "Can't discuss it here"
is to the point, and may even bring a smile to the OP's face.

And that would be a good thing.

it might be interesting as to why it is undefined.

 

[Richard Bos]

it isn't nonesense. It's the absolute truth. I've seen quite radical
changes in behaviour between different versions of the same compiler.

Moreover, if you do not expect a significant change in behaviour between
different versions of an implementation, why bring out a new version at
all? Tempora mutantur, nos et mutamur in illis - for values of "nos"
that include compilers as well as programmers.

Richard

 

[Igmar Palsenberg]

It is not necessary, 'tis true. But it should work right, anyway.

Why ? Invoking undefinied behaviour gives different results on multiple
platforms, on multiple versions of the same compiler, and with different
compilers. If you code undefined behaviour, expect things to break.

To all those who think it *should* : Please stay away from compilers and
code. People who do write conforming code already have to cope with bad
written shit like the OP posted.

True. But it *shouldn't* (see above) change unless there's a good reason
for it to do so.

Ah, and that is because it breakes behaviour that is undefined in the
first place ? *don't* write code like this, since it will break one way
or the other.



Igmar

 

[Dave Thompson]

Don't ever do that. Never. The behaviour is not portable. Unary
operators only make sense when used alone.

Nit: you mean mutating operators: assignment and increment/decrement.
Unary operators include +x -x &x *x !x ~x and sizeof x which can and
(always?) should be used with other operators.

- David.Thompson1 at worldnet.att.net