Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

Unexpected answer, compiler bug?

 
 
Golden California Girls
Guest
Posts: n/a
 
      12-25-2007
santosh wrote:
> Port Pirie wrote:
>
>> Hi,
>>
>> I ran the program below. It should print out 2 but actually it prints
>> out 1. What's going on? Should I report a bug against the compiler?
>>
>> Thanks.
>>
>>
>> void main()
>> {
>> int a=1;
>> a=a++;
>> printf("%d", a);
>> }

>
> You have invoked undefined behaviour thrice. Firstly void main is not
> the proper prototype. Proper forms are int main(void) or int main(int,
> char**). Secondly you access an object to modify it's value twice
> within a sequence point. Thirdly you are calling a variadic function
> with no prototype in scope.
>
> Please read the FAQ at the following link:
>
> <http://www.c-faq.com/>
> <http://www.clc-wiki.net/>
>


Why don't you answer his question? If his complier isn't issuing warnings about
these things he may indeed need to report a bug, just not the one he thinks.

 
Reply With Quote
 
 
 
 
Mike Wahler
Guest
Posts: n/a
 
      12-25-2007

"Golden California Girls" <(E-Mail Removed)> wrote in message
news:XK6dnXfJt8bB0OzanZ2dnUVZ_o2vnZ2d@championbroa dband.com...
> santosh wrote:
>> Port Pirie wrote:
>>
>>> Hi,
>>>
>>> I ran the program below. It should print out 2 but actually it prints
>>> out 1. What's going on? Should I report a bug against the compiler?
>>>
>>> Thanks.
>>>
>>>
>>> void main()
>>> {
>>> int a=1;
>>> a=a++;
>>> printf("%d", a);
>>> }

>>
>> You have invoked undefined behaviour thrice. Firstly void main is not
>> the proper prototype. Proper forms are int main(void) or int main(int,
>> char**). Secondly you access an object to modify it's value twice
>> within a sequence point. Thirdly you are calling a variadic function
>> with no prototype in scope.
>>
>> Please read the FAQ at the following link:
>>
>> <http://www.c-faq.com/>
>> <http://www.clc-wiki.net/>
>>

>
> Why don't you answer his question?


The first question ("What's going on?") was answered: The
behavior is undefined, thus *anything* is possible, including the
reported result.

> If his complier isn't issuing warnings about
> these things he may indeed need to report a bug, just not the one he
> thinks.


And above the second question ("Should I report a bug against the
compiler?")
was also answered.

AFAIK, there's nothing in his code for which the
standard requires a diagnostic. Warnings might
be nice, but that's simply a quality-of-implementation
issue, not a 'bug'.

-Mike


 
Reply With Quote
 
 
 
 
Golden California Girls
Guest
Posts: n/a
 
      12-26-2007
Mike Wahler wrote:
> "Golden California Girls" <(E-Mail Removed)> wrote in message
> news:XK6dnXfJt8bB0OzanZ2dnUVZ_o2vnZ2d@championbroa dband.com...
>> Why don't you answer his question?

>
> The first question ("What's going on?") was answered: The
> behavior is undefined, thus *anything* is possible, including the
> reported result.
>
>> If his complier isn't issuing warnings about
>> these things he may indeed need to report a bug, just not the one he
>> thinks.

>
> And above the second question ("Should I report a bug against the
> compiler?")
> was also answered.
>
> AFAIK, there's nothing in his code for which the
> standard requires a diagnostic. Warnings might
> be nice, but that's simply a quality-of-implementation
> issue, not a 'bug'.
>


So the standard doesn't require some message or action when you depart from it.
Interesting. I'd say not a good standard, in fact not a standard at all. Why
even have it?
 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      12-26-2007
Golden California Girls wrote:

> Mike Wahler wrote:
>> "Golden California Girls" <(E-Mail Removed)> wrote in message
>> news:XK6dnXfJt8bB0OzanZ2dnUVZ_o2vnZ2d@championbroa dband.com...
>>> Why don't you answer his question?

>>
>> The first question ("What's going on?") was answered: The
>> behavior is undefined, thus *anything* is possible, including the
>> reported result.
>>
>>> If his complier isn't issuing warnings about
>>> these things he may indeed need to report a bug, just not the one he
>>> thinks.

>>
>> And above the second question ("Should I report a bug against the
>> compiler?")
>> was also answered.
>>
>> AFAIK, there's nothing in his code for which the
>> standard requires a diagnostic. Warnings might
>> be nice, but that's simply a quality-of-implementation
>> issue, not a 'bug'.
>>

>
> So the standard doesn't require some message or action when you depart
> from it. Interesting. I'd say not a good standard, in fact not a
> standard at all. Why even have it?


Syntax errors and constraint violations must produce a diagnostic but
other issues can be left undiagnosed by an implementation. It must also
document it's behaviour for all issues the Standard tags
as "implementation defined". It need not document undefined behaviour.

 
Reply With Quote
 
Harald van Dijk
Guest
Posts: n/a
 
      12-26-2007
On Tue, 25 Dec 2007 16:05:56 -0800, Golden California Girls wrote:
> So the standard doesn't require some message or action when you depart
> from it.
> Interesting. I'd say not a good standard, in fact not a standard at
> all. Why
> even have it?


The standard requires messages for the types of departures that can be
realistically diagnosed in the general case at compile time. If it
mandated anything beyond that, I doubt the standard would be more useful
than now; we would merely have more implementations that don't conform to
it.
 
Reply With Quote
 
Golden California Girls
Guest
Posts: n/a
 
      12-26-2007
santosh wrote:
> Golden California Girls wrote:
>
>> Mike Wahler wrote:
>>> "Golden California Girls" <(E-Mail Removed)> wrote in message
>>> news:XK6dnXfJt8bB0OzanZ2dnUVZ_o2vnZ2d@championbroa dband.com...
>>>> Why don't you answer his question?
>>> The first question ("What's going on?") was answered: The
>>> behavior is undefined, thus *anything* is possible, including the
>>> reported result.
>>>
>>>> If his complier isn't issuing warnings about
>>>> these things he may indeed need to report a bug, just not the one he
>>>> thinks.
>>> And above the second question ("Should I report a bug against the
>>> compiler?")
>>> was also answered.
>>>
>>> AFAIK, there's nothing in his code for which the
>>> standard requires a diagnostic. Warnings might
>>> be nice, but that's simply a quality-of-implementation
>>> issue, not a 'bug'.
>>>

>> So the standard doesn't require some message or action when you depart
>> from it. Interesting. I'd say not a good standard, in fact not a
>> standard at all. Why even have it?

>
> Syntax errors and constraint violations must produce a diagnostic but
> other issues can be left undiagnosed by an implementation. It must also
> document it's behaviour for all issues the Standard tags
> as "implementation defined". It need not document undefined behaviour.
>


I'm assuming the "It" you mention in your second sentence should read "The
implementation".

Your third sentence the "It" could stand for either "The standard" or "The
implementation".

In any case I'm not talking about some hypothetical implementation, I'm talking
about the standard itself.

My point is that the standard should not allow undefined behavior. It should
either tag it implementation defined so it gets documented or tag it as a syntax
or constraint violation.

Leaving things undefined is like how houses used to be wired in the USA. There
was a plug and you knew there was a neutral pin and a hot pin but had no clue
which pin had which, because the standard left it undefinable. People died
because of that. [1]

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



[1] It is Christmas time so a perfect example. Strings of lights used to have
fuses on each lead. Why? Because the person making the string of lights didn't
know which lead was hot. He had to hope the short tripped both fuses so the
string went cold. Fuses however don't all open at the same point. Sometimes
the one in the line that was cold opened first and the string was left hot. Now
there is a big safety issue on a fake metal Christmas tree or a real one that
tipped over and spilled water all over the floor. Today however because the
designer knows which lead is hot there is only one fuse and it is in the hot
lead. It opens and the string is safe. Standards should not leave things
undefined!
 
Reply With Quote
 
Chris Torek
Guest
Posts: n/a
 
      12-26-2007
In article <(E-Mail Removed)>,
Golden California Girls <(E-Mail Removed)> wrote:
>My point is that the standard should not allow undefined behavior. ...


In general, the more you pin things down, the slower they will have to
go. As we see over and over again in computing, it is more important to
get the wrong answer as fast as possible.

Seriously, there *are* languages that have no undefined behavior, and
languages that are much better specified than C (Ada, for instance, falls
into the latter category). If that is what you want, you should consider
these languages. There is a price to pay for this, though.

As for defining all behavior precisely, consider the following function:

void f(int *p, int *q) {
*p = (*q)++;
}

The semantics of this function, as defined by the C standard, say that
*p will be set to whatever *q used to have, and *q will be incremented,
so that:

int a, b = 42;
...
f(&a, &b);

leaves a set to 42, and b set to 43.

But what happens if we do:

f(&b, &b);

? The "C answer" is: "the effect is undefined". This makes it
easy for a compiler to generate code for f() that runs as fast as
possible, even if that means that this has some strange effect on
b() in a call like the last one.

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. In some languages, it is possible to specify this
-- but C is not one of those languages. 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.

Alternatively, you might argue that the compiler should be required
to generate code for f() that does something "well defined" even if
p and q both point to b. Some languages take such an approach --
but C is not one of those languages either; C allows compilers to
generate the fastest possible code, as long as it gets the right
answer whenever p and q point to different variables.

The original C standardization effort, which by most accounts was
wildly successful, attempted -- for the most part at least -- to
standardize existing practice, without inventing new features like
detecting invalid calls to f(). The C89 standard was rapidly
adopted quite widely. The later standardization effort, resulting
in C99, was clearly less successful: and it took the approach of
improving the language in various ways, inventing new features to
make programming easier and/or safer, instead of sticking with
existing practice.

I leave it to the reader to draw conclusions. (Well, one of mine --
not 100% serious, admittedly -- is at the top of this article. )
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
 
Reply With Quote
 
Mark McIntyre
Guest
Posts: n/a
 
      12-26-2007
On Tue, 25 Dec 2007 16:05:56 -0800, Golden California Girls wrote:

> So the standard doesn't require some message or action when you depart
> from it.


Not correct.
Many classes of error e.g. syntax errors and constraint violations,
require a diagnostic.
Others are left to the implementation to decide how to handle because the
result is implementation dependent. For example some implementations
support a startup function signature void main(), so forcing an
implementation to error this would be wrong.



 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      12-26-2007
Mark McIntyre said:

> On Tue, 25 Dec 2007 16:05:56 -0800, Golden California Girls wrote:
>
>> So the standard doesn't require some message or action when you depart
>> from it.

>
> Not correct.
> Many classes of error e.g. syntax errors and constraint violations,
> require a diagnostic.


In fact, those are two of only three classes of error for which the
Standard requires a diagnostic message during translation. The third is
deliberately programmer-induced: #error.

--
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
 
Reply With Quote
 
Mark McIntyre
Guest
Posts: n/a
 
      12-26-2007
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.

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

> [1] It is Christmas time so a perfect example. Strings of lights used
> to have fuses on each lead. Why?


Because if the cable broke half way along, both halves would be carrying
current and you could get fried off each half.

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

 
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