What if I told you that the correct result could be just about anything,
including demons flying out of your nose?
>
> This is what every compiled progam says. Inclusive MSVisualC Compiler
> with Debug options or /Ot fast-option.
>
> But do not dare to switch to the the /O2 option of MSVisualC Compiler.
> Then once your computer cannot calculate anymore:
>
> 0. 1
> 1. 7
> 2. 13
> 3. 19
> 4. 25
>
> So, up to Microsoft, 0 + 2 = 1 ?????. That's why their OS is so stable....
> Try to increase the "<< 1". It even gets worse.

Well, as it turns out, the bug is on the other side of the keyboard in
this case.[1]

There is a sequence point between the two modifications of x, so
there's no undefined behavior here. The C language doesn't specify
which of the two bit32()'s will be invoked first, so there is
unspecified behavior here. But the first two calls to bit32() are
going to return 1 and 2 respectively, giving:
1 + (2 << 1) which is 5, or
2 + (1 << 1) which is 4
for the first return of bit64(). (If this were undefined behavior, the
compiler would be free to do whatever it wanted. That's not the case
here -- he can reliably assume he'll get 4 or 5 ... he just can't
assume which one he'll get.)

(The two outputs he shows (1 and 2 for the first call to bit64())
aren't possible from the code he posted ... but I assume his test code
actually had "x++" instead of "++x".)

Brett Frankenberger <> scribbled the following
on comp.lang.c:
> In article <bfej5d$727$01$-online.com>,
> Jakob Bieling <> wrote:
>>"Oliver Brausch" <> wrote in message
>>news:...
>>> static int x=0;
>>> int bit32() {
>>> return ++x;
>>> }
>>>
>>> int bit64() {
>>> return bit32() + (bit32() << 1);
>>> }
>>
>> You try to change a variable twice, which is invalid, ie. undefined
>>behaviour.
> There is a sequence point between the two modifications of x, so
> there's no undefined behavior here. The C language doesn't specify
> which of the two bit32()'s will be invoked first, so there is
> unspecified behavior here. But the first two calls to bit32() are
> going to return 1 and 2 respectively, giving:
> 1 + (2 << 1) which is 5, or
> 2 + (1 << 1) which is 4
> for the first return of bit64(). (If this were undefined behavior, the
> compiler would be free to do whatever it wanted. That's not the case
> here -- he can reliably assume he'll get 4 or 5 ... he just can't
> assume which one he'll get.)
> (The two outputs he shows (1 and 2 for the first call to bit64())
> aren't possible from the code he posted ... but I assume his test code
> actually had "x++" instead of "++x".)

Actually, yes they are. He has undefined behaviour - void main(). 1 and
2 are as legal outputs as 4 and 5, and so is "your mother was a hamster
and your father smelt of elderberries".

Yes, of course, but I wasn't responding to that. I was responding to
the claim that calling bit32() twice, as shown above, was undefined
behavior. And it's not. I specifically didn't show the void main()
part of the code.

As a practical matter, if he fixed the void main() thing, he's not
going to get a different result -- he'll still get one of the two
possible outcomes from bit64(). So he'll end up with a program that
has unspecified (but not undefined) behavior.

On Sun, 20 Jul 2003 18:29:35 GMT, "Falcon Kirtarania" <>
wrote:
>> 'void main' is illegal. It is *always* 'int main'.
>No, it is not. However, int main has always been considered MUCH better
>practice, because it allows for escapes and return codes.

Unspecified behaviour. It is absolutely to be expected that two
compilers will give different results. And I would just guess that the
code you posted is not the one that produced this output anyway; maybe
bit32 () contained an x++ instead of a ++x? If you took a programming
course with Microsoft, then maybe you can demand your money back.

Falcon Kirtarania wrote:
> Yes, but it is still legal, in that it will compile. I am not saying void
> main should be considered good practice, only that it is still compilable
> and (for all intents and purposes) works, as long as you don't give a crap
> about certain results.

Lots of things compile that are not standard or "illegal" by standard.

Falcon Kirtarania <> scribbled the following
on comp.lang.c:
> Any compiler I've used never called it.

You haven't used every compiler there is. And even if you had, nothing
would stop anyone from writing a new compiler where void main() was
illegal.
The moral of the story is: When the ISO C standard and your compiler
are giving you different ideas, trust the ISO C standard.
> "Thore B. Karlsen" <> wrote in message
> news:...
>> On Sun, 20 Jul 2003 18:29:35 GMT, "Falcon Kirtarania" <>
>> wrote:
>>
>> >> 'void main' is illegal. It is *always* 'int main'.
>>
>> >No, it is not. However, int main has always been considered MUCH better
>> >practice, because it allows for escapes and return codes.
>>
>> No, it's illegal. Read the standards.

On Sun, 20 Jul 2003 19:19:34 GMT, "Falcon Kirtarania" <>
wrote:
>Yes, but it is still legal, in that it will compile. I am not saying void
>main should be considered good practice, only that it is still compilable
>and (for all intents and purposes) works, as long as you don't give a crap
>about certain results.

The fact that one or several compilers accepts a piece of code does not
mean it is legal code.

Hours? If you've read all of the replies to your post and understand
what you've been told, that's not too bad considering all the lessons
you've (hopefully) learned -- and you'll be a better programmer (and
USENET poster) for it.

It's common for a novice programmer to blame the compiler, but
resist the temptation. Remember:

"...I don't think there is any question about it. It can only
be attributable to human error. This sort of thing has cropped
up before and it has always been due to human error."
--HAL 9000

It does, as long as you are considering only the standards of those
compilers.

"Thore B. Karlsen" <> wrote in message
news:...
> On Sun, 20 Jul 2003 19:19:34 GMT, "Falcon Kirtarania" <>
> wrote:
>
> >Yes, but it is still legal, in that it will compile. I am not saying
void
> >main should be considered good practice, only that it is still compilable
> >and (for all intents and purposes) works, as long as you don't give a
crap
> >about certain results.
>
> The fact that one or several compilers accepts a piece of code does not
> mean it is legal code.
>
> --
> Be seeing you.

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!