Plz explain me the following code

[Tim Rentsch]

Hmm. Good point. Assuming that the specified ordering doesn't actually
mean that things MUST be evaluated in that order, only that they must
not produce detectably different results, that's probably viable.

Even if compilers can do 99% of the possible optimizations
in such cases, I don't see any reason to further burden
the compiler to provide a feature that IMO (and also
those of many other people) has a negative utility.
If the language semantics specifies an order of evaluation
for, eg, function call arguments, that will just encourage
people to write tricky code that depends on that ordering.
I don't see any reason to encourage people to write tricky
code; there's already more than enough encouragement on
that front.

 

[Tim Rentsch]

Good example! Logging calls are in fact a case where I may genuinely
not care about the order of side effects, even though it's quite possible
that there will be observable differences betwween two possible choices.

C lets me specify what I want:

x = f();
x += g();

but also lets me express "really, either's fine".

Exactly. If a particular order is desired, it can be gotten, and
then it's clear in the code that the order might matter in that
particular case.

 

[Tim Rentsch]

If you have a processor which can do multiple things in parallel it
can be even more interesting. If the compiler knows you don't care
what order things are done in it can produce code which allows the
processor to do them in parallel. If it has to preserve the order then
it has to make sure the processor at least appears to preserve the
order slowing things down.

This raises an interesting question. In the abstract machine
must different operations be done in /some/ order, or
can they really be done in parallel? For example,

static volatile int x, y;

...

int a = x + y;

If a side-effect of accessing 'x' is to instantaneously
add 3 to 'y', and a side-effect of accessing 'y' is to
instantaneously add 5 to 'x', must 'a' necessarily get
the value 3 or 5, or might it get some other value (such
as 0)?

I believe C99 (more specifically n1256) is somewhat ambiguous
on this point. What about n1336? Anyone have a position
to offer?

 

[Tim Rentsch]

Wouldn't this be tantamount to turning all undefined behavior
into implementation-defined behavior?

No, only those areas of undefined behavior where the
host platform offered some fairly clearcut definitions
for what such behaviors should do.

That's not to say I think the suggestion is workable
necessarily, but it is not as broad a stroke as
making all undefined behavior be implementation-defined.

 

[Tim Rentsch]

[...]
Perhaps replacing UB with something like "anything left undefined
will, on hosted implementations, behave in a manner consistent with
the host"? So, dereferencing a NULL pointer on Unix can't launch
nuclear missiles, since Unix says it should SEGV.
[...]

void launch_missiles(int);
signal (SIGSEGV, launch_missiles);
strcpy (NULL, "Dr. Strangelove");

Facetious, yes -- But if the program has a launch_missiles()
function, how would you guarantee that U.B. could never cause the
function to run? The U.B. wouldn't even need to call the function
directly; it might pollute some piece of data that the program later
uses to make the launch decision (for example, it might mis-classify
the radar echoes from a flock of migrating geese as the trajectories
of a horde of incoming enemy missiles).

The only way I can imagine such a guarantee working would be for
the implementation to detect every instance of U.B. and then raise an
uncatchable SIGUB or something of the kind. Detecting every use of
an uninitialized variable, every read of a union element that wasn't
the last stored, every use of a pointer to free()d memory, ... That's
a huge burden to put on the implementation, and might not be do-able
even in principle.

I come away with a different conclusion, namely, that
/some/ UB will be defined, not that all must be. Saying
"anything left undefined will behave in a manner consistent
with the host" could still mean some things will be
(for all pratical purposes) undefined. The point is
to divide UB into two camps, one camp where there is
a reasonable expectation based on what the host will
do, and one where there is no useful expectation because
what the host is likely to do could corrupt the program
in unforseeable ways. In assembly language on x86,
I don't worry about signed integer overflow, because
I know nothing bad will happen. However, I do worry
about doing a store through a rogue pointer, since
whatever data is corrupted could have quite unforeseen
(and unforseeable, in general) consequences.

Does that way of looking at things make more sense?

 

[Tim Rentsch]

Chapter and verse please.

In C the order of evaluation b() + c() is unspecified. The only what
is specified is that both b() and f() must be executed to get +
executed. That includes that b() and c() can be executed in parallel
when the CPU can do so. Still tricky because C says nothing about
multithreading, it does neither allow nor disallow executing multiple
statements or whole functions in parallel.

Of course in the actual machine b() and c() might execute
in parallel if that's consistent with the semantics of
the abstract machine.

However, in the abstract machine, the executions of b() and c()
cannot overlap. Unfortunately the Standard doesn't state
this requirement as directly as one might like, but it
is stated clearly enough in a Defect Report:

http://www.open-std.org/jtc1/sc22/WG14/www/docs/dr_087.htm

 

[Herbert Rosenau]

And how is the compiler supposed to determine that (excluding the special
case where b() and c() are defined in the same translation unit as the
caller)?

When b() and c() are one of the standard function the compiler can
know what they do even without seeing them. If they are not inside the
same translation units and not standard the compiler has no chance.

--
Tschau/Bye
Herbert

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

 

[Keith Thompson]

When b() and c() are one of the standard function the compiler can
know what they do even without seeing them. If they are not inside the
same translation units and not standard the compiler has no chance.

Unless the implementation does link-time optimization.