Hello friends,

I am quite familiar with C and have coded a lot. But I get stumped on 
precedence rules, and I use paranthesis always. Can one of you out there 
explain how the value of s is evaluated in the following code snippet?

int a=5,s=0;
s=(++a) + (a++) + (--a) + (a--);

Thanks in advance.

Prasad. 

Prasad said:

> Hello friends,
> 
> I am quite familiar with C and have coded a lot. But I get stumped on
> precedence rules, and I use paranthesis always. Can one of you out there
> explain how the value of s is evaluated in the following code snippet?
> 
> int a=5,s=0;
> s=(++a) + (a++) + (--a) + (a--);

Precedence is not the issue here. The issue is order of evaluation, which 
is unspecified in C. Because of that unspecified behaviour, the code falls 
foul of the following dictum from 3.3 (Expressions) of C89:

   "Between the previous and next sequence point an object shall have its 
stored value modified at most once by the evaluation of an expression.  
Furthermore, the prior value shall be accessed only to determine the value 
to be stored."

The wording is almost identical in C99:

"Between the previous and next sequence point an object shall have its 
stored value modified at most once by the evaluation of an expression. 
Furthermore, the prior value shall be read only to determine the value to 
be stored."

What this means is that your code, which modifies a value more than once 
between consecutive sequence points, exhibits undefined behaviour. 
Therefore, any result - or none at all - is permissible.

Solution: break the statement up into multiple statements that express your 
intent precisely. For example:

s = ++a;
s += a++;
s += --a;
s += a--;

(if that's what you meant).

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Prasad wrote:
> 
> I am quite familiar with C and have coded a lot. But I get stumped
> on precedence rules, and I use paranthesis always. Can one of you
> out there explain how the value of s is evaluated in the following
> code snippet?
> 
> int a=5,s=0;
> s=(++a) + (a++) + (--a) + (a--);

That's an illegal statement.  It has no discernable value.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

CBFalconer said:

> Prasad wrote:
>> 
>> I am quite familiar with C and have coded a lot. But I get stumped
>> on precedence rules, and I use paranthesis always. Can one of you
>> out there explain how the value of s is evaluated in the following
>> code snippet?
>> 
>> int a=5,s=0;
>> s=(++a) + (a++) + (--a) + (a--);
> 
> That's an illegal statement.

No, it isn't. Its behaviour is undefined, but it's not against the law. 
Compilers aren't even obliged to diagnose it.

> It has no discernable value.

On the contrary, the problem with it is that it has at least two 
discernable values.

For example, if we evaluate left-to-right, it is easy to see how we can get 
a = 5, and s = 24.
If we evaluate right-to-left, again it is easy to see how we can get a = 5, 
s = 16.

It is less easy to see how we might get other results - but if we bear in 
mind that the compiler has licence to behave as if all the sub-expressions 
are independent of each other, it becomes a little easier to imagine. It 
is not difficult to find worked examples in mocked-up assembly language in 
comp.lang.c archives, that demonstrate how a variety of results are 
possible.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Richard Heathfield wrote:
> Prasad said:
> 
>> Hello friends,
>>
>> I am quite familiar with C and have coded a lot. But I get stumped on
>> precedence rules, and I use paranthesis always. Can one of you out there
>> explain how the value of s is evaluated in the following code snippet?
>>
>> int a=5,s=0;
>> s=(++a) + (a++) + (--a) + (a--);
> 
> Precedence is not the issue here. The issue is order of evaluation, which 
> is unspecified in C. Because of that unspecified behaviour, the code falls 
> foul of the following dictum from 3.3 (Expressions) of C89:
> 
>    "Between the previous and next sequence point an object shall have its 
> stored value modified at most once by the evaluation of an expression.  
> Furthermore, the prior value shall be accessed only to determine the value 
> to be stored."
> 
> The wording is almost identical in C99:
> 
> "Between the previous and next sequence point an object shall have its 
> stored value modified at most once by the evaluation of an expression. 
> Furthermore, the prior value shall be read only to determine the value to 
> be stored."
> 
> What this means is that your code, which modifies a value more than once 
> between consecutive sequence points, exhibits undefined behaviour. 
> Therefore, any result - or none at all - is permissible.
> 
> Solution: break the statement up into multiple statements that express your 
> intent precisely. For example:
> 
> s = ++a;
> s += a++;
> s += --a;
> s += a--;

....or simply

s = 4 * (a + 1);


August

Richard Heathfield wrote:
> CBFalconer said:
> 
>> Prasad wrote:
>>> I am quite familiar with C and have coded a lot. But I get stumped
>>> on precedence rules, and I use paranthesis always. Can one of you
>>> out there explain how the value of s is evaluated in the following
>>> code snippet?
>>>
>>> int a=5,s=0;
>>> s=(++a) + (a++) + (--a) + (a--);
>> That's an illegal statement.
> 
> No, it isn't. Its behaviour is undefined, but it's not against the law. 
> Compilers aren't even obliged to diagnose it.
> 
>> It has no discernable value.
> 
> On the contrary, the problem with it is that it has at least two 
> discernable values.
> 
> For example, if we evaluate left-to-right, it is easy to see how we can get 
> a = 5, and s = 24.
> If we evaluate right-to-left, again it is easy to see how we can get a = 5, 
> s = 16.
> 
> It is less easy to see how we might get other results - but if we bear in 
> mind that the compiler has licence to behave as if all the sub-expressions 
> are independent of each other, it becomes a little easier to imagine. It 
> is not difficult to find worked examples in mocked-up assembly language in 
> comp.lang.c archives, that demonstrate how a variety of results are 
> possible.

Here's one:
You can also get ((6 + 5 + 4 + 5) = 20),
regardless of direction of evaluation,
and then (a) is incremented twice and decremented twice.

-- 
pete

August Karlstrom said:

> Richard Heathfield wrote:

<snip>

>> Solution: break the statement up into multiple statements that express
>> your intent precisely. For example:
>> 
>> s = ++a;
>> s += a++;
>> s += --a;
>> s += a--;
> 
> ...or simply
> 
> s = 4 * (a + 1);

If that were his intent, yes. (It may not have been.)

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Hello,

Thanks for all the clarifications. As should be obvious, I defenitely don't 
want to use this code in any application. I posted this just out of 
curiosity as I could not find an explanation for the value arrived at by the 
compiler ( which is 20 ).

In another part of this thread, Pete has mentioned that 20 could be a 
possible answer, though I couldn't make out how. Hope he will tell me. (or 
am i being dumb? )

Prasad.

"Richard Heathfield" <rjh@see.sig.invalid> wrote in message 
news:AaydndgM9pkctz3VnZ2dnUVZ8u2dnZ2d@bt.com...
> August Karlstrom said:
>
>> Richard Heathfield wrote:
>
> <snip>
>
>>> Solution: break the statement up into multiple statements that express
>>> your intent precisely. For example:
>>>
>>> s = ++a;
>>> s += a++;
>>> s += --a;
>>> s += a--;
>>
>> ...or simply
>>
>> s = 4 * (a + 1);
>
> If that were his intent, yes. (It may not have been.)
>
> -- 
> Richard Heathfield <http://www.cpax.org.uk>
> Email: -http://www. +rjh@
> Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
> "Usenet is a strange place" - dmr 29 July 1999 

"Prasad" <pkp_0000@yahoo.com> wrote in message news:g7pp9i$mcd$1@aioe.org...
> Hello,
>
> Thanks for all the clarifications. As should be obvious, I defenitely 
> don't want to use this code in any application. I posted this just out of 
> curiosity as I could not find an explanation for the value arrived at by 
> the compiler ( which is 20 ).
>
> In another part of this thread, Pete has mentioned that 20 could be a 
> possible answer, though I couldn't make out how. Hope he will tell me. (or 
> am i being dumb? )
>

You've received several good replies.  Now you might make
a little effort and figure out the rest yourself.

-- Bob Day

Prasad wrote:
> Hello,
> 
> Thanks for all the clarifications. As should be obvious, I defenitely don't 
> want to use this code in any application. I posted this just out of 
> curiosity as I could not find an explanation for the value arrived at by the 
> compiler ( which is 20 ).
> 
> In another part of this thread, Pete has mentioned that 20 could be a 
> possible answer, though I couldn't make out how. Hope he will tell me. (or 
> am i being dumb? )

int a=5,s=0;
s=(++a) + (a++) + (--a) + (a--);

You can also get ((6 + 5 + 4 + 5) = 20),
regardless of direction of evaluation,
and then (a) is incremented twice and decremented twice.

Followup-To:comp.lang.c

You have to understand the concept of sequence points
and values and side effects.

N869
        Evaluation of an expression may produce side effects.
        At  certain  specified
        points in the execution sequence called sequence points, all
        side effects of previous evaluations shall be  complete  and
        no  side  effects of subsequent evaluations shall have taken
        place.

A statement terminator semicolon is an example of sequence point.
Assignment is not a sequence point.
Assignment is an example of side effect.

Expression of object type,
can be completely described in terms of value and side effects.
Between two sequence points,
evaluations and side effects can occur in any order.

The only sequence point here:
     s=(++a) + (a++) + (--a) + (a--);
is the semicolon.

And so, (a) starts with an initial value of 5,
it is evaluated 4 times, incremented twice and decremented twice.

Here's the meaning of the code:

(++a) means to increment (a).
The value of the expression is the value after the increment,
but the increment can happen any time
after the previous sequence point
and before the next sequence point.
The initial value of (a) is 5.
The value after the increment is 6.
The value of (++a) is 6.

(a++) means to increment (a).
The value of the expression is the value before the increment,
but the increment can happen any time
after the previous sequence point
and before the next sequence point.
The initial value of (a) is 5.
The value before the increment is 5.
The value of (a++) is 5.

(--a) means to decrement (a).
The value of the expression is the value after the decrement,
but the decrement can happen any time
after the previous sequence point
and before the next sequence point.
The initial value of (a) is 5.
The value after the decrement is 4.
The value of (--a) is 4.

(a--) means to decrement (a).
The value of the expression is the value before the decrement ,
but the decrement can happen any time
after the previous sequence point
and before the next sequence point.
The initial value of (a) is 5.
The value before the decrement is 5.
The value of (++a) is 5.

6 + 5 + 4 + 5 = 20

However, it is not the case that the result is limited
to what you can construe out of that code.
The way it is, is that code like that,
is considered by the C standard committee
to be so needlessly complicated in meaning,
that it is classified as causing undefined behavior,
which means that no matter what the program does for that code,
it's not a compiler bug, it's your bug.

N869
        Between the previous and next sequence point an  object
        shall  have  its  stored  value modified at most once by the
        evaluation of an expression.

-- 
pete

Prasad wrote:
> 
> Thanks for all the clarifications. As should be obvious, I
> defenitely don't want to use this code in any application. I
> posted this just out of curiosity as I could not find an
> explanation for the value arrived at by the compiler ( which is
> 20 ).
> 
> In another part of this thread, Pete has mentioned that 20 could
> be a possible answer, though I couldn't make out how. Hope he
> will tell me. (or am i being dumb? )

As I recall you posted some code that had undefined behavior.
Anything can happen, so suggesting mechanisms is pointless. 
Running it could also erase all files on your hard disk.

Please do not top-post.  Your answer belongs after (or intermixed
with) the quoted material to which you reply, after snipping all
irrelevant material.  See the following links:

  <http://www.catb.org/~esr/faqs/smart-questions.html>
  <http://www.caliburn.nl/topposting.html>
  <http://www.netmeister.org/news/learn2quote.html>
  <http://cfaj.freeshell.org/google/>  (taming google)
  <http://members.fortunecity.com/nnqweb/>  (newusers)

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

Richard Heathfield wrote:
> CBFalconer said:
>> Prasad wrote:
>>>
>>> I am quite familiar with C and have coded a lot. But I get stumped
>>> on precedence rules, and I use paranthesis always. Can one of you
>>> out there explain how the value of s is evaluated in the following
>>> code snippet?
>>>
>>> int a=5,s=0;
>>> s=(++a) + (a++) + (--a) + (a--);
>>
>> That's an illegal statement.
> 
> No, it isn't. Its behaviour is undefined, but it's not against the
> law. Compilers aren't even obliged to diagnose it.
> 
>> It has no discernable value.
> 
> On the contrary, the problem with it is that it has at least two
> discernable values.

No, since the behaviour is undefined, it can also erase all files
on all disks.  I consider this an undiscernable value.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

In article <48A0C7AA.A0CB3231@yahoo.com>, cbfalconer@yahoo.com says...
> Richard Heathfield wrote:
> > CBFalconer said:
> >> Prasad wrote:
> >>>
> >>> I am quite familiar with C and have coded a lot. But I get stumped
> >>> on precedence rules, and I use paranthesis always. Can one of you
> >>> out there explain how the value of s is evaluated in the following
> >>> code snippet?
> >>>
> >>> int a=5,s=0;
> >>> s=(++a) + (a++) + (--a) + (a--);
> >>
> >> That's an illegal statement.
> > 
> > No, it isn't. Its behaviour is undefined, but it's not against the
> > law. Compilers aren't even obliged to diagnose it.
> > 
> >> It has no discernable value.
> > 
> > On the contrary, the problem with it is that it has at least two
> > discernable values.
> 
> No, since the behaviour is undefined, it can also erase all files
> on all disks.  I consider this an undiscernable value.
> 
I can't help but feel that this argument is unproductive. Yes - it is 
understood that according to the "standard" it is undefined. But in the 
real world "undefined" is not the equivalent of "anything can happen", 
but rather that those who write the compilers do not have to take any 
particular care to ensure that the line will compile sensibly. 

Similarly, accessing an out of bounds array element is an example of 
undefined behaviour> But I think that we can all guarantee that there is 
no compiler designed to delete all your files and send a threatening e-
mail to your boss every time you make a minor typo in a program.

I feel Richard's explanation for why it is undefined is far more useful 
that the often parroted "anything can happen" comment.

Mike

mike <m.fee@irl.cri.replacethiswithnz> writes:

> In article <48A0C7AA.A0CB3231@yahoo.com>, cbfalconer@yahoo.com says...
>> Richard Heathfield wrote:
>> > CBFalconer said:
>> >> Prasad wrote:
>> >>>
>> >>> I am quite familiar with C and have coded a lot. But I get stumped
>> >>> on precedence rules, and I use paranthesis always. Can one of you
>> >>> out there explain how the value of s is evaluated in the following
>> >>> code snippet?
>> >>>
>> >>> int a=5,s=0;
>> >>> s=(++a) + (a++) + (--a) + (a--);
>> >>
>> >> That's an illegal statement.
>> > 
>> > No, it isn't. Its behaviour is undefined, but it's not against the
>> > law. Compilers aren't even obliged to diagnose it.
>> > 
>> >> It has no discernable value.
>> > 
>> > On the contrary, the problem with it is that it has at least two
>> > discernable values.
>> 
>> No, since the behaviour is undefined, it can also erase all files
>> on all disks.  I consider this an undiscernable value.
>> 
> I can't help but feel that this argument is unproductive. Yes - it is 
> understood that according to the "standard" it is undefined. But in the 
> real world "undefined" is not the equivalent of "anything can happen", 
> but rather that those who write the compilers do not have to take any 
> particular care to ensure that the line will compile sensibly. 

Hence the anything can happen.  And anything do happen, in particular
when the OS doesn't provide any protection.  If the line doesn't
compile sensibly, you can get random bytes in the execution path, and
therefore really random behavior, including disk erasing.  On a unix
system you could hope for a segfault, but while unicies are more or
less resistant to random code, some holding as little as less than one
second, and some up to a few minutes, before the kernel is crashed.


> Similarly, accessing an out of bounds array element is an example of 
> undefined behaviour> But I think that we can all guarantee that there is 
> no compiler designed to delete all your files and send a threatening e-
> mail to your boss every time you make a minor typo in a program.

If the out of bound access is writting the instructions to that effect
in the code after the PC, of course it will do that, as any virus
knows it very well.


> I feel Richard's explanation for why it is undefined is far more useful 
> that the often parroted "anything can happen" comment.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

READ THIS BEFORE OPENING PACKAGE: According to certain suggested
versions of the Grand Unified Theory, the primary particles
constituting this product may decay to nothingness within the next
four hundred million years.

CBFalconer said:

> Richard Heathfield wrote:
>> CBFalconer said:
>>> Prasad wrote:
>>>>
<snip>
>>>>
>>>> int a=5,s=0;
>>>> s=(++a) + (a++) + (--a) + (a--);
>>>
>>> That's an illegal statement.
>> 
>> No, it isn't. Its behaviour is undefined, but it's not against the
>> law. Compilers aren't even obliged to diagnose it.
>> 
>>> It has no discernable value.
>> 
>> On the contrary, the problem with it is that it has at least two
>> discernable values.
> 
> No, since the behaviour is undefined, it can also erase all files
> on all disks.  I consider this an undiscernable value.

Yes, I am happy to agree that it has an undiscernable value *as well*. But 
that's not what you first said. You said it had "no discernable value". I 
can discern (at least) two values, and others here have demonstrated that 
they, too, can discern (at least) two values. Therefore, the claim that it 
has "no discernable value" is (at least) doubly wrong. Whilst you 
correctly point out that it also has "an undiscernable value", this is 
irrelevant to my argument.

Whilst the Standard doesn't eliminate by fiat the risk of the compiler 
erasing all files on all disks as a result of this particular line of 
code, that risk is nevertheless so laughably small as to be not worth 
considering. If you choose to guard against it, to be logically consistent 
you should also guard against much more likely risks such as that of your 
key employees winning the national lottery and quitting, or an alien 
spaceship crashing into your office building.

The risk of getting the wrong value (that is, a value you weren't 
expecting) is considerably higher, and worth guarding against by 
specifying the calculation more carefully.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Richard Heathfield wrote:
> CBFalconer said:
> 
>> Prasad wrote:
>>> I am quite familiar with C and have coded a lot. But I get stumped
>>> on precedence rules, and I use paranthesis always. Can one of you
>>> out there explain how the value of s is evaluated in the following
>>> code snippet?
>>>
>>> int a=5,s=0;
>>> s=(++a) + (a++) + (--a) + (a--);
>> That's an illegal statement.
> 
> No, it isn't. Its behaviour is undefined, but it's not against the law. 
> Compilers aren't even obliged to diagnose it.

Neither are they obliged to compile it.

Running software that can translate and execute a C program,
is what an implementation of C is.

Whether or not running software
can translate and execute a text file
containing the line identified by CBFalconer as "illegal",
has no bearing on whether or not
that running software is a C implementation.

Code that contains that line, isn't a C program,
it's just gibberish that looks like a C program;
and if your compiler does compile it,
then you have fooled your compiler.

Followup-To:comp.lang.c

-- 
pete

In article <MPG.230b9782617dd26b98968c@news.comnet.net.nz>, mike 
<m.fee@irl.cri.replacethiswithnz> writes
>I can't help but feel that this argument is unproductive. Yes - it is
>understood that according to the "standard" it is undefined. But in the
>real world "undefined" is not the equivalent of "anything can happen",
>but rather that those who write the compilers do not have to take any
>particular care to ensure that the line will compile sensibly.

True. But, for example, the resulting code might corrupt variables 
outside those appearing in the expression. Or stack pointers. Which in 
turn could result in one system call being transmuted into another; say 
"open file" into "delete file".

>Similarly, accessing an out of bounds array element is an example of
>undefined behaviour> But I think that we can all guarantee that there is
>no compiler designed to delete all your files and send a threatening e-
>mail to your boss every time you make a minor typo in a program.

No, but look at how many viruses and other threads rely on buffer 
overflow.

-- 
Clive D.W. Feather                       | Home: <clive@davros.org>
Tel: +44 20 8495 6138 (work)             | Web:  <http://www.davros.org>
Fax: +44 870 051 9937                    | Work: <clive@demon.net>
Please reply to the Reply-To address, which is:  <clive@davros.org>

In article <obZ2elMUKxoIFwOk@romana.davros.org>, clive@on-the-
train.demon.co.uk says...
> In article <MPG.230b9782617dd26b98968c@news.comnet.net.nz>, mike 
> <m.fee@irl.cri.replacethiswithnz> writes
> >I can't help but feel that this argument is unproductive. Yes - it is
> >understood that according to the "standard" it is undefined. But in the
> >real world "undefined" is not the equivalent of "anything can happen",
> >but rather that those who write the compilers do not have to take any
> >particular care to ensure that the line will compile sensibly.
> 
> True. But, for example, the resulting code might corrupt variables 
> outside those appearing in the expression. Or stack pointers. Which in 
> turn could result in one system call being transmuted into another; say 
> "open file" into "delete file".
> 
> >Similarly, accessing an out of bounds array element is an example of
> >undefined behaviour> But I think that we can all guarantee that there is
> >no compiler designed to delete all your files and send a threatening e-
> >mail to your boss every time you make a minor typo in a program.
> 
> No, but look at how many viruses and other threads rely on buffer 
> overflow.
> 
I'm not trying to be arguementative here, but just trying to point out 
that any typo or logic error or uncorrected input error could do the 
same thing, as could the cosmic-ray induced corruption of a single bit 
anywhere in a program. But in practice, it is rather unlikely. I have 
managed to destabilise my PC on numerous occasions due to a bug-induced 
crash (maybe because I am stuck with Windows), but have never done any 
significant damage. So to me a bug due to an 'undefined' statement is no 
better or worse than any other programming bug.

But there seems to be a culture within the c programming community that 
almost demonises the _evil_ of undefined statements. The other common 
offhand remark that I have seen more than once is "It's undefined - it 
could make demons fly out of your nose". Now I accept that standards-
based programming is probably a good thing: if you can write a 
conforming program then you can (in theory at least) predict what it 
will do. (Well actually you can't, as Turing demonstrated!) But in the 
real world, with typos, programmer error, compiler bugs, operating 
system bugs, hardware failure - an undefined statement is probably no 
worse than any other bug.
Mike

mike wrote:
) I'm not trying to be arguementative here, but just trying to point out 
) that any typo or logic error or uncorrected input error could do the 
) same thing,  ... <snip>
) <snip> ...   But in the 
) real world, with typos, programmer error, compiler bugs, operating 
) system bugs, hardware failure - an undefined statement is probably no 
) worse than any other bug.

There is a significant issue you have overlooked that separates
undefined-behaviour-bugs.  Often, on one compiler, UB predictably does
the same thing.  A programmer could think that it's *supposed* to do that
and use it.  Testing cannot find the bug because it's _not there_ in the
compiled code, just in the source code.

The bug will only surface when the project switches to a new compiler.
(Or even a new version of the same compiler).

So, two significant issues, actually...
- Programmers may not know it's UB and come to rely on it.
- Bugs are only in source code and may not appear in compiled code.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

On Aug 11, 6:10=A0pm, CBFalconer <cbfalconer@yahoo.com> wrote:
> Prasad wrote:
>
> > Thanks for all the clarifications. As should be obvious, I
> > defenitely don't want to use this code in any application. I
> > posted this just out of curiosity as I could not find an
> > explanation for the value arrived at by the compiler ( which is
> > 20 ).
>
> > In another part of this thread, Pete has mentioned that 20 could
> > be a possible answer, though I couldn't make out how. Hope he
> > will tell me. (or am i being dumb? )
>
> As I recall you posted some code that had undefined behavior.
> Anything can happen, so suggesting mechanisms is pointless.
> Running it could also erase all files on your hard disk.

AFAICS, that could only happen under two circumstances:

(a) The compiler produces instructions to erase all files in the hard
disk. (The creator of the compiler is mentally insane.)
(b) The OS is insecure enough to let process misbehavior cause this
operation. (The OS is useless.)

Personally, I know of no such (useless) compiler, and of no such
(useless) OS.

In any other case, such as a side effect produced by the OS because of
an unrelated event, the "anything can happen" fact also applies if the
behavior *were* defined.

<snip>

Sebastian