Order of execution

[divyank.rastogi]

Just curious:
What would be the effect of making j volatile in the above expression?
Would it still be undefined?

Thanks in advance.

 

[Keith Thompson]

Just curious:
What would be the effect of making j volatile in the above expression?
Would it still be undefined?

Yes.

 

[Chris Hills]

Chris Hills said:


I lost the two strange headers and the prototype, changed void main to int
main, added a return statement, and changed uint16_t to int, to match the
printfs. I then compiled the program on three different compilers (two
different operating systems).

Here are my results:

gcc Microsoft C Borland C
2.95.3 12.00.8168 5.6
Linux Windows XP Windows XP
---------------------------------
20 20 20
30 30 30
20 20 20
10 10 10
40 40 <------> 50
40 40 <------> 50
40 40 <------> 50
40 40 <------> 30
20 20 20
60 <------> 50 50
40 <------> 50 50
40 <------> 30 30

All three of these results differ from each other and from all of your
published results in at least one respect (marked <------> for your
convenience).

Thanks I have put then in the list.
http://www.phaedsys.demon.co.uk/chris/sweng/swengtips3a.htm

Two of the results are (much) later versions of compilers already listed
and as you point out they are not the same as the earlier ones.

So not only are the results different from compiler vendor to compiler
vendor but between versions of the same compiler!!!

any other additions welcome.

 

[Kenneth Brody]

(e-mail address removed) wrote: [...]
Still feel a little
puzzled, please someone could explain this.

They all invoke undefined behavior, so anything can happen.
Contrary to popular believe in comp.lang.c, this does not mean that
demons may fly out of your nose but that the compiler is not required
to interpret these statements in any one well defined way, or to do
anything that is consistent and repeatable, or to do anything that
looks "reasonable" to you.

[...]

And causing demons to fly out your nose is a perfectly valid way to
"interpret these statements", as far as the standard is concerned.

While it is highly unlikely that a compiler writer will go out of
his way to cause such behavior,

You didn't spend much time around compiler writers, did you?

Well, I did have second thoughts about that statement.

Perhaps "highly unlikely that a commercially available compiler
will have such a feature slip through testing and make it into
the release version"?

[...]

However, "the odds are" is not the same as "the standard requires",
and "undefined behavior" is exactly that -- undefined. The standard
places absolutely no restrictions on the outcome, and does not
prohibit the creation of nasal demons.

I understand that perfectly well. I am aware that asking a compiler to
process something like "i = i++ + ++i;" could cause any, or all, or
any combination of the following to happen, without violating the C
standard:

a) The customary appearance of nasal demons. [... snip rest of list ...]

Still, while presenting things this way may elicit a chuckle from
comp.lang.c veterans, it is not the right pedagogical approach to be
used when answering questions from beginners.

I think the point is to make them stop and say "huh?"

It's a much stronger reinforcement for "don't do that" than "well,
you know, it may be, perhaps, that in some future version of the
compiler that you're using, your program may possibly give you a
different answer".

I believe the way my answer was worded was both correct and more
helpful to the OP.
Let's bring up the nasal demons later, when he is mature enough and
strong enough to face the truth.

Isn't the truth "although the standard allows nasal demons, it's not
very likely"?

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Mark McIntyre]

Roberto Waltman wrote:

Perhaps "highly unlikely that a commercially available compiler
will have such a feature slip through testing and make it into
the release version"?

Laugh? I had to get clean underwear.....

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Chris Hills]

Roberto Waltman wrote:
(e-mail address removed) wrote:
[...]
Still feel a little
puzzled, please someone could explain this.

They all invoke undefined behavior, so anything can happen.
Contrary to popular believe in comp.lang.c, this does not mean that
demons may fly out of your nose but that the compiler is not required
to interpret these statements in any one well defined way, or to do
anything that is consistent and repeatable, or to do anything that
looks "reasonable" to you.
[...]

And causing demons to fly out your nose is a perfectly valid way to
"interpret these statements", as far as the standard is concerned.

While it is highly unlikely that a compiler writer will go out of
his way to cause such behavior,

You didn't spend much time around compiler writers, did you?

Well, I did have second thoughts about that statement.

Perhaps "highly unlikely that a commercially available compiler
will have such a feature slip through testing and make it into
the release version"?

http://www.phaedsys.demon.co.uk/chris/sweng/swengtips3a.htm

Two of the results are (much) later versions of compilers already listed
and as you point out they are not the same as the earlier ones.

So not only are the results different from compiler vendor to compiler
vendor but between versions of the same compiler!!!

any other additions welcome.

 

[Dietmar Schindler]

...
a) The customary appearance of nasal demons. [... snip rest of list ...]

Still, while presenting things this way may elicit a chuckle from
comp.lang.c veterans, it is not the right pedagogical approach to be
used when answering questions from beginners.

I think the point is to make them stop and say "huh?"

It's a much stronger reinforcement for "don't do that" than "well,
you know, it may be, perhaps, that in some future version of the
compiler that you're using, your program may possibly give you a
different answer".

I think it is a misbelief that the average person who is engaged in
computer programming - even if new to C - would be less impressed by
comprehensible facts than by fairy tales.

 

[Chris Hills]

...
a) The customary appearance of nasal demons. [... snip rest of list ...]

Still, while presenting things this way may elicit a chuckle from
comp.lang.c veterans, it is not the right pedagogical approach to be
used when answering questions from beginners.

I think the point is to make them stop and say "huh?"

It's a much stronger reinforcement for "don't do that" than "well,
you know, it may be, perhaps, that in some future version of the
compiler that you're using, your program may possibly give you a
different answer".

I think it is a misbelief that the average person who is engaged in
computer programming - even if new to C - would be less impressed by
comprehensible facts than by fairy tales.[/QUOTE]


The problem is working out which are the facts and which the fairy
tales. I have seen both mis-represented over the years.

 

[Stephen Sprunk]

I think it is a misbelief that the average person who is engaged in
computer programming - even if new to C - would be less impressed by
comprehensible facts than by fairy tales.

Saying "the result of this might do what you expect or it might do something
else" is nowhere near as clear as saying "demons might fly out of your
nose". Obviously the latter is an exaggeration of the reality, but it makes
the point more clearly.

IMHO, it's rather frustrating for someone new to C to wrap their mind around
the idea that C doesn't actually define what happens in many cases. Humor
helps in moments of frustration.

S

 

[Keith Thompson]

Saying "the result of this might do what you expect or it might do
something else" is nowhere near as clear as saying "demons might fly
out of your nose". Obviously the latter is an exaggeration of the
reality, but it makes the point more clearly.

IMHO, it's rather frustrating for someone new to C to wrap their mind
around the idea that C doesn't actually define what happens in many
cases. Humor helps in moments of frustration.

Agreed. Any hypothetical consequence short of nasal demons can leave
the impression that there are only a limited number of things that can
possibly go wrong.

"It can scribble over other variables and crash your program."
"Ok, but obviously it can't crash the operating system."
Yes, as far as the standard is concerned, it certainly can.

"It can crash your operating system."
"Ok, but it obviously can't cause any physical damage."
Yes, as far as the standard is concerned, it certainly can -- and
there are real-world examples of this happening.

"It can make demons fly out of your nose."
"Ok, but it ... um ... ok, I won't do that."

 

[Morris Dovey]

Keith Thompson (in (e-mail address removed)) said:

| "It can crash your operating system."
| "Ok, but it obviously can't cause any physical damage."
| Yes, as far as the standard is concerned, it certainly can --
| and there are real-world examples of this happening.
|
| "It can make demons fly out of your nose."
| "Ok, but it ... um ... ok, I won't do that."

I've seen it happen. Over 2500 remote CPUs on a satellite broadcast
network killed their hard drives. The third time it happened, the
company died. The cause: code riddled with undefined behavior in
combination with a refusal to sanitize input data streams.

 

[Roberto Waltman]

Keith Thompson said:
| "It can crash your operating system."
| "Ok, but it obviously can't cause any physical damage."
| Yes, as far as the standard is concerned, it certainly can --
| and there are real-world examples of this happening.
|
| "It can make demons fly out of your nose."
| "Ok, but it ... um ... ok, I won't do that."

I've seen it happen. Over 2500 remote CPUs on a satellite broadcast
network killed their hard drives. The third time it happened, the
company died. The cause: code riddled with undefined behavior in
combination with a refusal to sanitize input data streams.

Also the original IBM-PC: You could burn the monitor's flyback coil if
the video parameters were not set up correctly. I'm sure there are
many other examples out there.

I still prefer the set of "all horrible things that may happen if your
code invokes undefined behavior" to contain only things that are
physically possible in this world.

 

[Ian Collins]

Also the original IBM-PC: You could burn the monitor's flyback coil if
the video parameters were not set up correctly. I'm sure there are
many other examples out there.

I still prefer the set of "all horrible things that may happen if your
code invokes undefined behavior" to contain only things that are
physically possible in this world.

I'm sure the real cause of

http://news.bbc.co.uk/cbbcnews/hi/uk/newsid_3459000/3459375.stm

was some dodgy C code....

 

[Walter Roberson]

I still prefer the set of "all horrible things that may happen if your
code invokes undefined behavior" to contain only things that are
physically possible in this world.

Nasal demons haven't been proven to be physically impossible ;-)

 

[Stephen Sprunk]

Also the original IBM-PC: You could burn the monitor's flyback coil if
the video parameters were not set up correctly. I'm sure there are
many other examples out there.

In the instructions for configuring video modes for XFree86, they make it
sound like anything you do that isn't absolutely perfect will trash your
monitor and possibly video card. I haven't killed a monitor yet (mainly
because the warning made me extremely cautious when making changes), but
it's a perfect modern example of how code _can_ cause physical damage.

Unfortunately, the single most common result of UB is the system doing
exactly what the programmer expected it to do -- right up until you're doing
a demo for a customer, at which point it does the opposite.

I still prefer the set of "all horrible things that may happen if your
code invokes undefined behavior" to contain only things that are
physically possible in this world.

No matter what plausible example you try to give, someone will come up with
a rebuttal. They can't rebut nasal demons because they're laughing too hard
to type

S

 

[Kenneth Brody]

Roberto Waltman wrote:
[... "nasal demons" and UB ...]

Also the original IBM-PC: You could burn the monitor's flyback coil if
the video parameters were not set up correctly. I'm sure there are
many other examples out there.

The Tandy TRS-80 Model 2. The video memory was bank-switched with
the top 2K of system memory. While bank-switched in, the video
signal was turned off. Normally, this was only for a fraction of
a millisecond, as data was written to the video memory. However,
if you kept it switched in too long, you could burn out the video
hardware. (I believe it was the flyback transformer that would
overload.)

When version 2 of the O/S included a print spooler, the despooler
code was in the bank-switched system memory shared with video memory.
And the despooler was called on the hardware timer tick interrupt.
Well, I'm sure you can picture what happened when you didn't disable
interrupts while writing to video memory.

I still prefer the set of "all horrible things that may happen if your
code invokes undefined behavior" to contain only things that are
physically possible in this world.

Just because there isn't any current technology which can cause
demons to fly out one's nose doesn't mean it's not "physically
possible".


"After the rocket quits our air and really starts on its longer
journey [to the moon], its flight would be neither accelerated
nor maintained by the [proposed by Goddard solid rocket based
on] explosions of the charges. To claim that it would be is to
deny a fundamental law of dynamics, and only Dr. Einstein and
his chosen dozen, so few and fit, are licensed to do that." -
Editorial comments, The New York Times, January 13, 1920.


"A Correction. On Jan. 13, 1920, "Topics of the Times," and
editorial-page feature of the The New York Times, dismissed the
notion that a rocket could function in vacuum and commented on
the ideas of Robert H. Goddard, the rocket pioneer, as follows:
[...]
Further investigation and experimentation have confirmed the
findings of Isaac Newton in the 17th Century and it is now
definitely established that a rocket can function in a vacuum
as well as in an atmosphere. The Times regrets the error." -
The New York Times, July 17, 1969.


"Any sufficiently advanced technology is indistinguishable from
magic." - Arthur C. Clarke, "Profiles of The Future", 1961

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Chris Dollin]

Also the original IBM-PC: You could burn the monitor's flyback coil if
the video parameters were not set up correctly. I'm sure there are
many other examples out there.

I still prefer the set of "all horrible things that may happen if your
code invokes undefined behavior" to contain only things that are
physically possible in this world.

You're prepared to bet your nose on your confidence that you know
what's physically possible?

 

[ozbear]

Keith Thompson (in (e-mail address removed)) said:

| "It can crash your operating system."
| "Ok, but it obviously can't cause any physical damage."
| Yes, as far as the standard is concerned, it certainly can --
| and there are real-world examples of this happening.
|
| "It can make demons fly out of your nose."
| "Ok, but it ... um ... ok, I won't do that."

I've seen it happen. Over 2500 remote CPUs on a satellite broadcast
network killed their hard drives. The third time it happened, the
company died. The cause: code riddled with undefined behavior in
combination with a refusal to sanitize input data streams.

--

I don't believe this.

Oz

 

[Andrew Poelstra]

I don't believe this.

A: People who reply with "I don't believe you" won't be taken seriously.
There was a recent thread about this.

B: Even if that isn't true, there's nothing unbelievable in the story. Why
wouldn't you believe it?

 

[Morris Dovey]

Andrew Poelstra (in (e-mail address removed)) said:

|| On Wed, 5 Jul 2006 16:11:06 -0500, "Morris Dovey"
||
||| Keith Thompson (in (e-mail address removed)) said:
|||
|||| "It can crash your operating system."
|||| "Ok, but it obviously can't cause any physical damage."
|||| Yes, as far as the standard is concerned, it certainly can --
|||| and there are real-world examples of this happening.
||||
|||| "It can make demons fly out of your nose."
|||| "Ok, but it ... um ... ok, I won't do that."
|||
||| I've seen it happen. Over 2500 remote CPUs on a satellite
||| broadcast network killed their hard drives. The third time it
||| happened, the company died. The cause: code riddled with
||| undefined behavior in combination with a refusal to sanitize
||| input data streams.
||
|| I don't believe this.
|
| A: People who reply with "I don't believe you" won't be taken
| seriously. There was a recent thread about this.
|
| B: Even if that isn't true, there's nothing unbelievable in the
| story. Why wouldn't you believe it?

My Qwest news server didn't carry ozbear's reply. I'm not sure how to
provide you with convincing evidence; but the outfit was FarmDayta and
they were located in Urbandale, Iowa USA.

Each of the three times this happened, they were obliged to pay UPS to
ship the thousands of damaged units back to their shop for removal of
the hard drive, installation of a new drive, installation of their
proprietary software, unit test, and UPS shipping back to subscribers.

Subscribers - many of whom relied on the near-real-time market
information to conduct their business - started dropping the service
after the second failure.

I've forgotten what the average and total repair costs were; but it
was more than the company could afford. I think they folded in 1994.

Somewhat closer to the Land of Oz, a Delta Airlines MD-11 carrying
(under test) air-ground networking electronics flying from Portland to
Nagano put an incorrectly formatted message into the Asian equivalent
of our ARINC network that brought the entire Asian network down -
producing a /lot/ of angry finger-pointing. That fiasco was brought
about by a single instance of an errant <ESC> character. We decided
that output filtering/checking might help - but I'm still amazed that
the network was so vulnerable. Presumably, it's been fixed.

Murphy is alive and well. This stuff really does happen in real life.