By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,851 Members | 2,097 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,851 IT Pros & Developers. It's quick & easy.

Order of execution

P: n/a
Hi all,
one of the recent post gives the macro to do swap

#define SWAP(m, n) (tmp = (m), (m) = (n), (n) = tmp)

This macro will work, if the execution is from left to right.

That is step 1) tmp=m
step 2) m=n
step 3) n=tmp

But I hope order of execution is decided by the compiler.
Does C specification is saying any thing about this order of exectuion?

Will this macro work on all compilers?

Plz share your thoughts...

Thanks
Sabi

Jun 28 '06 #1
Share this Question
Share on Google+
42 Replies


P: n/a
"Sabiyur" <Sa***********@gmail.com> wrote:
Hi all,
one of the recent post gives the macro to do swap

#define SWAP(m, n) (tmp = (m), (m) = (n), (n) = tmp)

This macro will work, if the execution is from left to right.

That is step 1) tmp=m
step 2) m=n
step 3) n=tmp

But I hope order of execution is decided by the compiler.
Does C specification is saying any thing about this order of exectuion?

Will this macro work on all compilers?

Yes, it will work on all C compilers. The comma operator used in the
macro guarantees left-to-right evaluation.

(Of course, tmp must be defined first.)

Jun 28 '06 #2

P: n/a
"Sabiyur" <Sa***********@gmail.com> wrote:
one of the recent post gives the macro to do swap

#define SWAP(m, n) (tmp = (m), (m) = (n), (n) = tmp)

This macro will work, if the execution is from left to right.
No, it won't; it will work, _if_ (and that's a much bigger if) tmp has
the same type as m and n, or a compatible one.
That is step 1) tmp=m
step 2) m=n
step 3) n=tmp

But I hope order of execution is decided by the compiler.
Does C specification is saying any thing about this order of exectuion?


Yes. Not generally, but there's a sequence point at the commas. This
means that whatever trickery happens under the bonnet, the program much
at least behave as if it was executed left-to-right.

However, using this macro means that you have to declare a third object;
this object _must_ be called tmp; it must not hold an important value at
the moment this macro is called; and it must be declared to have a type
that is compatible with both m and n (so no using it to swap long
doubles one line, and structs the next line. So much for generality).

All this means that using this macro is probably rather more bother than
just writing this line out every time you need it. At least that means
you can swap several types of value, without having to resort to hacks
such as

{
the_appropriate_type tmp;
SWAP(object_1, object_2_;
}

(Oh, and of course by forgoing the macro you can also swap objects which
are themselves called tmp, but that's a lesser advantage.)

Richard
Jun 28 '06 #3

P: n/a
Sabiyur schrieb:
Hi all,
one of the recent post gives the macro to do swap

#define SWAP(m, n) (tmp = (m), (m) = (n), (n) = tmp)

This macro will work, if the execution is from left to right.

That is step 1) tmp=m
step 2) m=n
step 3) n=tmp

But I hope order of execution is decided by the compiler.
Does C specification is saying any thing about this order of exectuion?

Will this macro work on all compilers?


C has a concept called "sequence points".
Between two consecutive sequence points, the order of execution
is not determined by the C standard -- it only has to be
semantically correct.
However, you can be sure that the code before the sequence point
is evaluated after the sequence point (or that your compiler /
platform behaves as if this is the case).
The comma operator gives you such a sequence point, i.e.
the preprocessed version of
tmp = (m)
will be executed before the preprocessed version of
(m) = (n), (n) = tmp
and, applying this rule once more,
(m) = (n)
is executed before
(n) = tmp

Read more on sequence points in the FAQ:
http://c-faq.com/expr/seqpoints.html
and the rest of chapter 3.

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Jun 28 '06 #4

P: n/a
Michael Mair wrote:
...

Will this macro work on all compilers?
C has a concept called "sequence points".
Between two consecutive sequence points, the order of execution
is not determined by the C standard -- it only has to be
semantically correct.
However, you can be sure that the code before the sequence point
is evaluated <-----> after the sequence point (or that your compiler /


Insert // "before the code that is" \\
platform behaves as if this is the case).
The comma operator gives you such a sequence point, i.e.
the preprocessed version of
tmp = (m)
will be executed before the preprocessed version of
(m) = (n), (n) = tmp
and, applying this rule once more,
(m) = (n)
is executed before
(n) = tmp

Read more on sequence points in the FAQ:
http://c-faq.com/expr/seqpoints.html
and the rest of chapter 3.

Cheers
Michael

Jun 28 '06 #5

P: n/a
Roberto Waltman schrieb:
Michael Mair wrote:
...

Will this macro work on all compilers?


C has a concept called "sequence points".
Between two consecutive sequence points, the order of execution
is not determined by the C standard -- it only has to be
semantically correct.
However, you can be sure that the code before the sequence point
is evaluated <-----> after the sequence point (or that your compiler /


Insert // "before the code that is" \\


That's what I meant to write -- thank you :-)

Cheers
Michael
platform behaves as if this is the case).

--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Jun 28 '06 #6

P: n/a
"Sabiyur" <Sa***********@gmail.com> wrote in message
news:11**********************@m73g2000cwd.googlegr oups.com...
But I hope order of execution is decided by the compiler.
Does C specification is saying any thing about this order of exectuion?
The compiler can do anything it wants as long as the resulting program
behaves as if it did exactly what you said, i.e. it should be impossible to
detect it's done anything differently.

You'll see this "as if" rule referred to frequently on c.l.c.
Will this macro work on all compilers?


It should work the same on any compiler (there's reasons it may fail, but it
would fail on all in those cases).

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
--
Posted via a free Usenet account from http://www.teranews.com

Jun 28 '06 #7

P: n/a
In article <11**********************@m73g2000cwd.googlegroups .com>,
Sabiyur <Sa***********@gmail.com> writes
Hi all,
one of the recent post gives the macro to do swap

#define SWAP(m, n) (tmp = (m), (m) = (n), (n) = tmp)

This macro will work, if the execution is from left to right.

That is step 1) tmp=m
step 2) m=n
step 3) n=tmp

But I hope order of execution is decided by the compiler.
Does C specification is saying any thing about this order of exectuion?

Will this macro work on all compilers?

Plz share your thoughts...


http://www.phaedsys.demon.co.uk/chri...swengtips3.htm
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 29 '06 #8

P: n/a
the result I got from following calculation is (i=10, j=2):
(i * j++) + (i * j) = 40
(i * j) + (i * j++) = 40
(i * j--) + (i * j) = 40
(i * j) + (i * j--) = 40
(i * ++j) + (i * j) = 60
(i * j) + (i * ++j) = 60
(i * ++j) + (i * --j) = 40
(i * --j) + (i * ++j) = 40

I realized that the '+' operator is not a sequence point, which means
either left or right part could have side effects. Still feel a little
puzzled, please someone could explain this.

Jun 29 '06 #9

P: n/a
ga*********@gmail.com said:
the result I got from following calculation is (i=10, j=2):
(i * j++) + (i * j) = 40
Undefined behaviour.
(i * j) + (i * j++) = 40
Undefined behaviour.
(i * j--) + (i * j) = 40
Undefined behaviour.
(i * j) + (i * j--) = 40
Undefined behaviour.
(i * ++j) + (i * j) = 60
Undefined behaviour.
(i * j) + (i * ++j) = 60
Undefined behaviour.
(i * ++j) + (i * --j) = 40
Undefined behaviour.
(i * --j) + (i * ++j) = 40
Undefined behaviour.
I realized that the '+' operator is not a sequence point, which means
either left or right part could have side effects. Still feel a little
puzzled, please someone could explain this.


Undefined behaviour - and the C Standard does not attempt to explain or
predict the results of undefined behaviour.

In other words, when you break the rules, you're on your own.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jun 29 '06 #10

P: n/a
On 29 Jun 2006 08:37:28 -0700, ga*********@gmail.com wrote:
the result I got from following calculation is (i=10, j=2):
(i * j++) + (i * j) = 40
(i * j) + (i * j++) = 40
(i * j--) + (i * j) = 40
(i * j) + (i * j--) = 40
(i * ++j) + (i * j) = 60
(i * j) + (i * ++j) = 60
(i * ++j) + (i * --j) = 40
(i * --j) + (i * ++j) = 40

I realized that the '+' operator is not a sequence point, which means
either left or right part could have side effects.
The would "have side effects" (changing the value of j) even if there
was a sequence point.
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.

Let's take the first example:

/* result = */ (i * j++) + (i * j) /* ; */

A compiler could translate this as if it was written in either one of
the following ways (and an infinite number of others.). None of them
is "incorrect".

(Lets assume i, j, tmp1, tmp2, tmp3 and result are all declared as
plain int.)

=====
tmp1 = i * j;
tmp2 = i * j;
j++;
result = tmp1 + tmp2;
====
tmp1 = i * j;
j++;
tmp2 = i * j;
result = tmp1 + tmp2;
=====
tmp1 = i * j;
tmp3 = j;
j = A_RANDOM_VALUE; /* In some architectures */
/* with multiple execution */
/* units, the increment was */
/* scheduled to run in */
/* parallel with following */
/* code, and the value of j */
/* is retrieved before the */
/* operation has been */
/* completed. */
/* Some architectures could */
/* trap this and terminate */
/* the program here. */
tmp2 = i * j;
j = tmp3 + 1;
result = tmp1 + tmp2;
=====
Jun 29 '06 #11

P: n/a
Roberto Waltman said:

<UB code examples snipped>
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,


Chapter and verse, please. :-)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jun 29 '06 #12

P: n/a
Roberto Waltman wrote:

On 29 Jun 2006 08:37:28 -0700, ga*********@gmail.com 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, there is nothing stopping one from
creating such behavior, and such behavior would still be conforming
to the standard.

The odds are that behaviour of code with things like "j++ + j" will
be one of two scenarios (returning either "j+j" or "j+j+1", with j
being incremented by one in both cases), but that is only because
the compiler writer simply allowed the undefined behavior to be
ignored, and treated the "j++" as if it were any other instance of
"j++" in a valid statement.

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.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
Jun 29 '06 #13

P: n/a
In article <ft********************@bt.com>, Richard Heathfield
<in*****@invalid.invalid> writes
ga*********@gmail.com said:
the result I got from following calculation is (i=10, j=2):
(i * j++) + (i * j) = 40


Undefined behaviour.
(i * j) + (i * j++) = 40


Undefined behaviour.
(i * j--) + (i * j) = 40


Undefined behaviour.
(i * j) + (i * j--) = 40


Undefined behaviour.
(i * ++j) + (i * j) = 60


Undefined behaviour.
(i * j) + (i * ++j) = 60


Undefined behaviour.
(i * ++j) + (i * --j) = 40


Undefined behaviour.
(i * --j) + (i * ++j) = 40


Undefined behaviour.
I realized that the '+' operator is not a sequence point, which means
either left or right part could have side effects. Still feel a little
puzzled, please someone could explain this.


Undefined behaviour - and the C Standard does not attempt to explain or
predict the results of undefined behaviour.

In other words, when you break the rules, you're on your own.


See the page linked to the one with the above lines

http://www.phaedsys.demon.co.uk/chri...wengtips3a.htm
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 29 '06 #14

P: n/a
In article <11*********************@j72g2000cwa.googlegroups. com>,
ga*********@gmail.com writes
the result I got from following calculation is (i=10, j=2):
(i * j++) + (i * j) = 40
(i * j) + (i * j++) = 40
(i * j--) + (i * j) = 40
(i * j) + (i * j--) = 40
(i * ++j) + (i * j) = 60
(i * j) + (i * ++j) = 60
(i * ++j) + (i * --j) = 40
(i * --j) + (i * ++j) = 40

I realized that the '+' operator is not a sequence point, which means
either left or right part could have side effects. Still feel a little
puzzled, please someone could explain this.


There is no defined way of processing a line. Some work left to right
others right to left and some middle out etc. With others it depends on
how the optimiser works on that particular architecture as to how it
does it.
I assume everyone also looked at the linked page

http://www.phaedsys.demon.co.uk/chri...wengtips3a.htm

which gave the outputs from several compilers highlighting the fact that
it is all Undefined Behaviour.

As it happens that line of above "results" is not the same as the other
FIVE versions recorded!!!

What was the compiler used? Does any one have any more differing
results. I will expand the table.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 29 '06 #15

P: n/a
Chris Hills said:
In article <ft********************@bt.com>, Richard Heathfield
<in*****@invalid.invalid> writes

In other words, when you break the rules, you're on your own.


See the page linked to the one with the above lines

http://www.phaedsys.demon.co.uk/chri...wengtips3a.htm


If you're interested in the results for some of the compilers I have here
that don't appear to be in your list, please post the source. (I started
typing it in, and got very bored very quickly!)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jun 29 '06 #16

P: n/a
Chris Hills wrote:
In article <lI********************@bt.com>, Richard Heathfield
<in*****@invalid.invalid> writes
Chris Hills said:
In article <ft********************@bt.com>, Richard Heathfield
<in*****@invalid.invalid> writes

In other words, when you break the rules, you're on your own.

See the page linked to the one with the above lines

http://www.phaedsys.demon.co.uk/chri...wengtips3a.htm
If you're interested in the results for some of the compilers I have here
that don't appear to be in your list, please post the source. (I started
typing it in, and got very bored very quickly!)

This was to run on a Keil C51 targeting a Philips 80C592 edit to as
required..

#include <REG592.H>
#include <inttypes.h>
#include <stdio.h>

static void init_serial(void);

void main(void)
{
uint16_t i = 10;
uint16_t j = 0;

init_serial();

j=2;
printf("i = %d, j = %d, i * j++ = %d \n", i, j, i* j++ );
j=2;
printf("i = %d, j = %d, i * ++j = %d \n", i, j, i* ++j);
j=2;
printf("i = %d, j = %d, i * j-- = %d \n", i, j, i* j-- );
j=2;
printf("i = %d, j = %d, i * --j = %d \n", i, j, i* --j );
j=2;
printf(" (i * j++ ) + (i * j ) = %d \n",(i * j++ ) + (i * j ) );
j=2;
printf(" (i * j ) + (i * j++ ) = %d \n",(i * j) + (i * j++ ) );
j=2;
printf(" (i * j++ ) + (i * j -- ) = %d \n",(i * j++ ) + (i * j-- ) );
j=2;
printf(" (i * j-- ) + (i * j ++ ) = %d \n",(i * j-- ) + (i * j ));


Something's wrong here...
j=2;
printf(" (i * ++j ) + (i * j) = %d \n",(i * --j ) + (i * j ));


And here.

Robert Gamble

Jun 29 '06 #17

P: n/a
In article <lI********************@bt.com>, Richard Heathfield
<in*****@invalid.invalid> writes
Chris Hills said:
In article <ft********************@bt.com>, Richard Heathfield
<in*****@invalid.invalid> writes

In other words, when you break the rules, you're on your own.


See the page linked to the one with the above lines

http://www.phaedsys.demon.co.uk/chri...wengtips3a.htm


If you're interested in the results for some of the compilers I have here
that don't appear to be in your list, please post the source. (I started
typing it in, and got very bored very quickly!)

This was to run on a Keil C51 targeting a Philips 80C592 edit to as
required..

#include <REG592.H>
#include <inttypes.h>
#include <stdio.h>

static void init_serial(void);

void main(void)
{
uint16_t i = 10;
uint16_t j = 0;

init_serial();

j=2;
printf("i = %d, j = %d, i * j++ = %d \n", i, j, i* j++ );
j=2;
printf("i = %d, j = %d, i * ++j = %d \n", i, j, i* ++j);
j=2;
printf("i = %d, j = %d, i * j-- = %d \n", i, j, i* j-- );
j=2;
printf("i = %d, j = %d, i * --j = %d \n", i, j, i* --j );
j=2;
printf(" (i * j++ ) + (i * j ) = %d \n",(i * j++ ) + (i * j ) );
j=2;
printf(" (i * j ) + (i * j++ ) = %d \n",(i * j) + (i * j++ ) );
j=2;
printf(" (i * j++ ) + (i * j -- ) = %d \n",(i * j++ ) + (i * j-- ) );
j=2;
printf(" (i * j-- ) + (i * j ++ ) = %d \n",(i * j-- ) + (i * j ));
j=2;
printf(" (i * ++j ) + (i * j) = %d \n",(i * --j ) + (i * j ));
j=2;
printf(" (i * j ) + (i * ++j ) = %d \n",(i * j) + (i * ++j));
j=2;
printf(" (i * ++j ) + (i * --j) = %d \n",(i * ++j ) + (i * --j ));
j=2;
printf(" (i * --j) + (i * ++j) = %d \n",(i * --j) + (i * ++j));

}

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 29 '06 #18

P: n/a
Chris Hills said:
This was to run on a Keil C51 targeting a Philips 80C592 edit to as
required..


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

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jun 30 '06 #19

P: n/a
Kenneth Brody wrote:
Roberto Waltman wrote:
ga*********@gmail.com 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? :)
there is nothing stopping one from
creating such behavior, and such behavior would still be conforming
to the standard.

The odds are that behaviour of code with things like "j++ + j" will
be one of two scenarios (returning either "j+j" or "j+j+1", with j
being incremented by one in both cases), but that is only because
the compiler writer simply allowed the undefined behavior to be
ignored, and treated the "j++" as if it were any other instance of
"j++" in a valid statement.

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.
b) Peace on Earth to all men of goodwill.
c) The discovery that ether and phlogiston are responsible, after all,
for the propagation of electromagnetic waves and heat, respectively.
d) The reversal of the movement of the planet's tectonic plates,
putting South America and Africa in a collision course. (You have been
warned, visit Buenos Aires while you can.)
e) The discovery of weapons of mass destruction in Iraq.
f) The selective reversal of the magnetic field on the platters in my
hard disk, in such a way that my Ubuntu Linux box will be downgraded
to a legitimate copy of Windows Vista, Service Pack 72.

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

Amicably yours,

Roberto Waltman.
Jun 30 '06 #20

P: n/a

Roberto Waltman wrote:
On 29 Jun 2006 08:37:28 -0700, ga*********@gmail.com wrote:
the result I got from following calculation is (i=10, j=2):
(i * j++) + (i * j) = 40
Just curious:
What would be the effect of making j volatile in the above expression?
Would it still be undefined?

Thanks in advance.
(i * j) + (i * j++) = 40
(i * j--) + (i * j) = 40
(i * j) + (i * j--) = 40
(i * ++j) + (i * j) = 60
(i * j) + (i * ++j) = 60
(i * ++j) + (i * --j) = 40
(i * --j) + (i * ++j) = 40

I realized that the '+' operator is not a sequence point, which means
either left or right part could have side effects.


The would "have side effects" (changing the value of j) even if there
was a sequence point.
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.

Let's take the first example:

/* result = */ (i * j++) + (i * j) /* ; */

A compiler could translate this as if it was written in either one of
the following ways (and an infinite number of others.). None of them
is "incorrect".

(Lets assume i, j, tmp1, tmp2, tmp3 and result are all declared as
plain int.)

=====
tmp1 = i * j;
tmp2 = i * j;
j++;
result = tmp1 + tmp2;
====
tmp1 = i * j;
j++;
tmp2 = i * j;
result = tmp1 + tmp2;
=====
tmp1 = i * j;
tmp3 = j;
j = A_RANDOM_VALUE; /* In some architectures */
/* with multiple execution */
/* units, the increment was */
/* scheduled to run in */
/* parallel with following */
/* code, and the value of j */
/* is retrieved before the */
/* operation has been */
/* completed. */
/* Some architectures could */
/* trap this and terminate */
/* the program here. */
tmp2 = i * j;
j = tmp3 + 1;
result = tmp1 + tmp2;
=====


Jun 30 '06 #21

P: n/a
"di*************@gmail.com" <di*************@gmail.com> writes:
Roberto Waltman wrote:
On 29 Jun 2006 08:37:28 -0700, ga*********@gmail.com wrote:
>the result I got from following calculation is (i=10, j=2):
>(i * j++) + (i * j) = 40


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


Yes.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jun 30 '06 #22

P: n/a
In article <3p********************@bt.com>, Richard Heathfield
<in*****@invalid.invalid> writes
Chris Hills said:
This was to run on a Keil C51 targeting a Philips 80C592 edit to as
required..


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/chri...wengtips3a.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.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 30 '06 #23

P: n/a
Roberto Waltman wrote:

Kenneth Brody wrote:
Roberto Waltman wrote:
ga*********@gmail.com 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:Th*************@gmail.com>
Jun 30 '06 #24

P: n/a
On Fri, 30 Jun 2006 11:44:21 -0400, in comp.lang.c , Kenneth Brody
<ke******@spamcop.net> wrote:
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
Jun 30 '06 #25

P: n/a
In article <44***************@spamcop.net>, Kenneth Brody
<ke******@spamcop.net> writes
Roberto Waltman wrote:

Kenneth Brody wrote:
>Roberto Waltman wrote:
>> ga*********@gmail.com 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/chri...wengtips3a.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.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 30 '06 #26

P: n/a
Kenneth Brody wrote:
>
Roberto Waltman wrote:
...
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.
--
Dietmar Schindler
Jul 5 '06 #27

P: n/a
In article <44***********@arcor.de>, Dietmar Schindler <dS***@arcor.de>
writes
>Kenneth Brody wrote:
>>
Roberto Waltman wrote:
>...
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.

The problem is working out which are the facts and which the fairy
tales. I have seen both mis-represented over the years.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jul 5 '06 #28

P: n/a
"Dietmar Schindler" <dS***@arcor.dewrote in message
news:44***********@arcor.de...
Kenneth Brody wrote:
>Roberto Waltman wrote:
a) The customary appearance of nasal demons.

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

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
--
Posted via a free Usenet account from http://www.teranews.com

Jul 5 '06 #29

P: n/a
"Stephen Sprunk" <st*****@sprunk.orgwrites:
"Dietmar Schindler" <dS***@arcor.dewrote in message
news:44***********@arcor.de...
>Kenneth Brody wrote:
>>Roberto Waltman wrote:
a) The customary appearance of nasal demons.

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.

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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jul 5 '06 #30

P: n/a
Keith Thompson (in ln************@nuthaus.mib.org) 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.

--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/DeSoto
Jul 5 '06 #31

P: n/a
"Morris Dovey" wrote:
>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.
Jul 5 '06 #32

P: n/a
Roberto Waltman wrote:
"Morris Dovey" wrote:
>>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.
I'm sure the real cause of

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

was some dodgy C code....

--
Ian Collins.
Jul 5 '06 #33

P: n/a
In article <sb********************************@4ax.com>,
Roberto Waltman <us****@rwaltman.netwrote:
>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 ;-)
--
There are some ideas so wrong that only a very intelligent person
could believe in them. -- George Orwell
Jul 6 '06 #34

P: n/a
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:Th*************@gmail.com>

Jul 6 '06 #35

P: n/a
"Roberto Waltman" <us****@rwaltman.netwrote in message
news:sb********************************@4ax.com...
"Morris Dovey" wrote:
>>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.
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

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
--
Posted via a free Usenet account from http://www.teranews.com

Jul 6 '06 #36

P: n/a
Roberto Waltman wrote:
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?

--
Chris "physics is scary, also imcomplete" Dollin
"A facility for quotation covers the absence of original thought." /Gaudy Night/

Jul 6 '06 #37

P: n/a
On Wed, 5 Jul 2006 16:11:06 -0500, "Morris Dovey" <mr*****@iedu.com>
wrote:
>Keith Thompson (in ln************@nuthaus.mib.org) 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
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jul 6 '06 #38

P: n/a
On 2006-07-06, ozbear <oz****@bigpond.comwrote:
On Wed, 5 Jul 2006 16:11:06 -0500, "Morris Dovey" <mr*****@iedu.com>
wrote:
>>Keith Thompson (in ln************@nuthaus.mib.org) 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?

--
Andrew Poelstra <http://www.wpsoftware.net/projects/>
To email me, use "apoelstra" at the above domain.
"You people hate mathematics." -- James Harris
Jul 7 '06 #39

P: n/a
Andrew Poelstra (in sl**********************@wpsoftware.net) said:

| On 2006-07-06, ozbear <oz****@bigpond.comwrote:
|| On Wed, 5 Jul 2006 16:11:06 -0500, "Morris Dovey"
|| <mr*****@iedu.comwrote:
||
||| Keith Thompson (in ln************@nuthaus.mib.org) 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 <ESCcharacter. 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.

--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/DeSoto
Jul 7 '06 #40

P: n/a
Keith Thompson wrote:
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."
A more probable dialog:

"It can make demons fly out of your nose."
"Stop taking those pills, and I might start taking you seriously."

--
Dietmar Schindler
Jul 7 '06 #41

P: n/a
Dietmar Schindler wrote:
Keith Thompson wrote:
>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."

A more probable dialog:

"It can make demons fly out of your nose."
"Stop taking those pills, and I might start taking you seriously."
I have seen several instances on this group more along the lines of:
"It can make demons fly out of your nose."
"LOL, that explains why my nose hurts so much! OK, I won't do
that."
This is especially the case IMHO when you don't stick to the same
ridiculous example, but instead mix things to give people some variety.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc
Jul 7 '06 #42

P: n/a

Richard Heathfield wrote:
Roberto Waltman said:

<UB code examples snipped>
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,

Chapter and verse, please. :-)
The Standard doesn't say anything can happen.
What it does say is that it imposes no requirements.
The absence of a requirement does not imply
a guarantee of possibility.

I'm sure you can find the section that defines
the term undefined behavior as easily as the
next person.

Jul 18 '06 #43

This discussion thread is closed

Replies have been disabled for this discussion.