Unix Programming - UB / sequence points (was Re: Qry : Behaviour of fgets -- ?)

This is Interesting: Free IT Magazines  
Home > Archive > Unix Programming > September 2007 > UB / sequence points (was Re: Qry : Behaviour of fgets -- ?)





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author UB / sequence points (was Re: Qry : Behaviour of fgets -- ?)
Kenneth Brody

2007-09-10, 1:16 pm

Rainer Weikusat wrote:
>
> rlb@hoekstra-uitgeverij.nl (Richard Bos) writes:

[...]
>
> It is not (generally) possible to execute microprocessor instructions
> which don't do something specific. But this speculation is besides the
> point. The bheaviours is undefined. This means it is undefined.


You've never run on a CPU which can perform more than one
instruction at a time, have you?

Consider, for example:

int i;
...
i = i++;

There is no reason to expect that the compiler can't generate
something along the lines of:

something \ These two instructions run in parallel
load r1,i /

store r1,i \ As do these
incr i /

This isn't an issue with "j = i++" because the store will write
to j. However, in this case, both instructions attempt to write
to i, causing a bus conflict and locking the system.

Perhaps the system has some protection against this, but it will
still fail depending on the value in i. Perhaps, for example, if
i is 0xffffffff and the increment causes an overflow exception to
occur while it is handling the collision exception.

Okay, I suppose you could say that this behavior is "defined" in
the sense that the outcome is not dependent on quamtum physics,
but it's still not "defined" in the sense that "the answer must
be A or B". (There are many people who stongly believe that the
only possible outcome of "i=3; i=i++;" is that i must contain the
value 3, and there are others who know about sequence points who
will insist that the only possible answers are that i contain the
value 3 or 4.)

And, regardless, the behavior is still "undefined" as far as the
C standard is concerned. Code that depends on a particular
compiler's particular code generator's output is asking for
trouble.

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


Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com