Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Unexpected answer, compiler bug?

Reply
Thread Tools

Unexpected answer, compiler bug?

 
 
Mark McIntyre
Guest
Posts: n/a
 
      12-26-2007
On Wed, 26 Dec 2007 04:37:07 +0000, Chris Torek wrote:

> Now, you might argue that the compiler should be able to detect that p
> and q both point to b, so that the call to f() should draw a diagnostic.


Though that's tricky if, as Chris notes, the function f() is in a library
that was compiled long long ago on a computer far far away -or worse yet,
is still being written by a co-worker 14,000 miles away in a different
timezone. I'm not aware of any compilers that can diagnose either the
past or the future!

> In C, f() can be compiled
> separately from the call to f(), and by the time you go to join
> the two together (the "link phase"), the information needed is
> allowed to have been, and usually has been, discarded.


.... and even if it hasn't, the runtime environment might be presented
with duff user input, eg the user was told to pick two _different_
objects but chose the same one twice. A lot of gets() type bugs come lack
of /programmer/ effort to assist users who enter "ten" instead of "10"...

Remember - if you design an idiot-proof system, the universe will design
a better class of idiot.

 
Reply With Quote
 
 
 
 
Harald van Dijk
Guest
Posts: n/a
 
      12-26-2007
On Wed, 26 Dec 2007 11:46:27 +0000, Mark McIntyre wrote:
> On Tue, 25 Dec 2007 20:01:42 -0800, Golden California Girls wrote:
>> My point is that the standard should not allow undefined behavior.

>
> That's a foolish point. If it did not allow some behaviour to be
> undefined, then it would have to document all behaviour on all platforms
> now and as-yet uninvented.


As the most simplistic example, it could say that everything not
explicitly defined is implementation-defined. Alternatively, it could
provide a reference implementation and require other implementations to
behave the same way, except where the behaviour is explicitly
unspecified. There are probably other possibilities I haven't thought of.
None probably would have worked well for C, but it's not nearly as absurd
as you suggest it is.
 
Reply With Quote
 
 
 
 
Mark McIntyre
Guest
Posts: n/a
 
      12-26-2007
On Wed, 26 Dec 2007 14:00:16 +0100, Harald van Dijk wrote:

>> As the most simplistic example, it could say that everything not

> explicitly defined is implementation-defined.


I think's playing with words. The difference between IB and UB is an
artefact of the standard. Also practically speaking, no document can
define all behaviours - it'd take an infinite amount of paper. Even the
Ada standard doesn't define what happens if I compile the code on Boxing
Day while naked and playing pinochle.

> Alternatively, it could
> provide a reference implementation and require other implementations to
> behave the same way, except where the behaviour is explicitly
> unspecified.


Yes, this approach is often used. The difficulty is that while it works
fine for stuff thats highly prescribed in the first place (say the
definition of a kilogram), it doesn't work well for general-purpose
stuff.

In the case of programming languages, it would force implementations to
support non-native features, which can be exceptionally costly in terms
of both dev effort and runtime.

> it's not nearly as absurd as you suggest it is.


Consider which languages are popular, widely ported and widely used. Are
they the ones with fully prescriptive standards? Or are they the ones
that leave the implementor plenty of scope to handle some behaviours as
best suits their environment?

 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      12-26-2007
Mark McIntyre wrote, On 26/12/07 11:46:
> On Tue, 25 Dec 2007 20:01:42 -0800, Golden California Girls wrote:


<snip>

>> Because the person making the string
>> of lights didn't know which lead was hot.

>
> Euh? Do you guys use DC in the states? If not, it doesn't matter which is
> live, they're both carrying 240/110 V. Follow 'em back to the pole where
> the phases split out....


Actually that is wrong in the UK. The neutral is bonded to earth at the
sub-station, although at your house it will be a bit away from the
ground voltage. See, for example, page 19 and on of this document
http://www2.theiet.org/Publish/WireR...no_adverts.pdf
It is the live that varies with respect to ground at the sub-station,
and this is why it is important that the live and neutral are not
swapped in your house.

This is all OT here so if you want to continue the discussion one
sensible place would be the IET forums which will be somewhere on
http://www.theiet.org/
--
Flash Gordon
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      12-26-2007
Mark McIntyre <(E-Mail Removed)> writes:
> On Tue, 25 Dec 2007 20:01:42 -0800, Golden California Girls wrote:
>> My point is that the standard should not allow undefined behavior.

>
> That's a foolish point. If it did not allow some behaviour to be
> undefined, then it would have to document all behaviour on all platforms
> now and as-yet uninvented. Thats obviously impossible. Furthermore it
> would proscribe implementations from providing extensions since if
> everything is defined, nothing can be added.


No, it's not obviously impossible. A language standard could
rigorously define the behavior of an abstract machine, and require all
implementations to implement that abstract machine exactly. But such
a language wouldn't really be C, even if it superficially looked like
it. In particular, implementations for real systems that differ from
the abstract machine couldn't easily take advantage of those systems'
features.

>> Perhaps the standard had better start with big bold face caps "This
>> standard leaves things undefined and therefore must not be used in any
>> case where harm (economic or physical) might come to anyone such as any
>> real world application."

>
> Perhaps it could start with "this standard expects its readers to have
> common sense, if you're too stoopid to wire up a 3-pin plug, then stop
> now".


Perhaps that's not the best example. I don't know how to wire up a
3-pin plug -- not because I'm stoopid, just because I've never had a
need to do it.

[...]

--
Keith Thompson (The_Other_Keith) <(E-Mail Removed)>
[...]
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Kenneth Brody
Guest
Posts: n/a
 
      12-27-2007
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
>
> On Dec 25, 12:46 pm, Port Pirie <(E-Mail Removed)> wrote:

[...]
> > int a=1;
> > a=a++;

[...]
> The key point to your answer is the line:
> a=a++;
>
> it evaluates a to 1 in right side, assigns 1 to a in left side, then
> increments a used in right side.


Wrong. It's undefined behavior, pure and simple.

Now, it's likely that the compiler will treat it as:

Do the following things before the next sequence point:

Store the value 1 into a.
Increment a.

However, it's free to do it in any order:

Store, then increment.
Increment, then store.
Store and increment at the same time, causing the computer
to hard-lock, and requiring a power-cycle to unlock it.

Also, as far as the C Standard is concerned, it's also free to
do none of the above, and perhaps generate code that reformats
the hard drive, after e-mailing your boss with your resignation
letter.

> Use prefix increment instead, like
> this:
>
> a = ++a;


Although your particular compiler may generate code that "works"
(ie: "does what you think you meant to say"), this too is an
example of pure undefined behavior.

> Of course, it's advisable you take into account all other advises
> about prototype of main() and enting output with \n.


As well as reading up on "undefined behavior" and "sequence points".

If you want to increment something, increment it:

a++;
or
++a;
or
a += 1;
or even
a = a + 1;

Just don't invoke UB.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <(E-Mail Removed)>

 
Reply With Quote
 
Mark McIntyre
Guest
Posts: n/a
 
      12-27-2007
On Wed, 26 Dec 2007 21:01:16 +0000, Flash Gordon wrote:

> Mark McIntyre wrote, On 26/12/07 11:46:
>> On Tue, 25 Dec 2007 20:01:42 -0800, Golden California Girls wrote:

>
> <snip>
>
>>> Because the person making the string
>>> of lights didn't know which lead was hot.

>>
>> Euh? Do you guys use DC in the states? If not, it doesn't matter which
>> is live, they're both carrying 240/110 V. Follow 'em back to the pole
>> where the phases split out....

>
> Actually that is wrong in the UK. The neutral is bonded to earth at the
> sub-station,


Correct. This is however highly misleading to know, as it would lead the
unwary to think that the neutral is at ground voltage, and consequently
electrocute themselves by grabbing it.

> although at your house it will be a bit away from the
> ground voltage.


You're quite right. Typically its about rms 240v away!

> It is the live that varies with respect to ground at the sub-station,
> and this is why it is important that the live and neutral are not
> swapped in your house.


Well, yes and no. Consider that you can plug light-bulbs in either way
round, and many appliances eg razors have only two completely reversible
pins. The problem is only with /earthed/ appliances (and humans).

> This is all OT here


indeed.
 
Reply With Quote
 
Mark McIntyre
Guest
Posts: n/a
 
      12-27-2007
On Wed, 26 Dec 2007 13:26:35 -0800, Keith Thompson wrote:

> Mark McIntyre <(E-Mail Removed)> writes:
>> On Tue, 25 Dec 2007 20:01:42 -0800, Golden California Girls wrote:
>>> My point is that the standard should not allow undefined behavior.

>>
>> That's a foolish point. If it did not allow some behaviour to be
>> undefined, then it would have to document all behaviour on all
>> platforms now and as-yet uninvented. Thats obviously impossible.

>
> No, it's not obviously impossible.


I said /all/ behaviour on /all/ platforms.

> A language standard could rigorously
> define the behavior of an abstract machine,


What, even the behaviour if I compile naked on a Wednesday?

>> Perhaps it could start with "this standard expects its readers to have
>> common sense, if you're too stoopid to wire up a 3-pin plug, then stop
>> now".

>
> Perhaps that's not the best example.


I chose it on purpose, because of hte OP's earlier analogy about
electrical standards.

> I don't know how to wire up a
> 3-pin plug -- not because I'm stoopid, just because I've never had a
> need to do it.


I suspect you could work it out pretty quickly.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      12-28-2007
Mark McIntyre <(E-Mail Removed)> writes:
> On Wed, 26 Dec 2007 13:26:35 -0800, Keith Thompson wrote:
>> Mark McIntyre <(E-Mail Removed)> writes:
>>> On Tue, 25 Dec 2007 20:01:42 -0800, Golden California Girls wrote:
>>>> My point is that the standard should not allow undefined behavior.
>>>
>>> That's a foolish point. If it did not allow some behaviour to be
>>> undefined, then it would have to document all behaviour on all
>>> platforms now and as-yet uninvented. Thats obviously impossible.

>>
>> No, it's not obviously impossible.

>
> I said /all/ behaviour on /all/ platforms.


Yes, I know.

>> A language standard could rigorously
>> define the behavior of an abstract machine,

>
> What, even the behaviour if I compile naked on a Wednesday?


Why not? Presumably the behavior should be exactly the same as if you
compile fully clothed on Thursday.

Consider an abstract machine with, say, fixed sizes for all the
predefined types, well-defined behavior on numeric overflow, a fixed
amount of memory with a simple linear addressing scheme, and so forth.
Each implementation must correctly emulate the abstract machine, with
no permitted variations. The language is rigorously tailored to the
abstract machine.

For a real machine that's not sufficiently similar to the abstract
machine, this might require the abstract machine to be emulated from
the ground up.

[snip]

--
Keith Thompson (The_Other_Keith) <(E-Mail Removed)>
[...]
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Mark McIntyre
Guest
Posts: n/a
 
      12-29-2007
On Thu, 27 Dec 2007 20:24:54 -0800, Keith Thompson wrote:

>>>
>>> No, it's not obviously impossible.

>>
>> I said /all/ behaviour on /all/ platforms.

>
> Yes, I know.


Then you'll understand that its impossible, since no standard can predict
the future.

>> What, even the behaviour if I compile naked on a Wednesday?

>
> Why not?


Because there's an infinite set of things that might happen (assuming you
subscribe to non-theistic models of time).

> Consider an abstract machine with, say, fixed sizes for all the
> predefined types, well-defined behavior on numeric overflow, a fixed
> amount of memory with a simple linear addressing scheme, and so forth.
> Each implementation must correctly emulate the abstract machine, with no
> permitted variations. The language is rigorously tailored to the
> abstract machine.


And now we're discussing my /other/ reason why even a standard that
completely defines everything relevant may be such a significant issue as
to render the point moot.

Incidentally, whats your point in debating this with me? Other than to
score points / out-pedant me?
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Unexpected compiler behavior relating to size_t and boost - VisualStudio 2005. Unknownmat C++ 9 07-15-2008 07:38 AM
Compiler Error Message: CS0007: Unexpected common language... FrigginMook ASP .Net 3 12-29-2007 10:15 AM
Compiler Error Message: The compiler failed with error code -1073741819 Ram ASP .Net 0 09-13-2005 09:52 AM
Can we use <compiler> tag to avoid RunTime Compiler error? Jack Wright ASP .Net 5 01-19-2004 04:36 PM
Compiler Error Message: The compiler failed with error code 128. Yan ASP .Net 0 07-21-2003 10:49 PM



Advertisments