By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
439,993 Members | 1,883 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 439,993 IT Pros & Developers. It's quick & easy.

Horrible Visual C Bug!

P: n/a
Hello,

have you ever heard about this MS-visual c compiler bug?
look at the small prog:
static int x=0;
int bit32() {
return ++x;
}

int bit64() {
return bit32() + (bit32() << 1);
}

void main(int argc, char **argv) {
int i;
for (i = 0; i < 5; i++) printf("%d. %d\n", i, bit64());
}
Ok, the (correct) result is:

0. 2
1. 8
2. 14
3. 20
4. 26

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.

Ever seen this? I costed me hours of debugging. Can I
sue Microsoft for this?

- Oliver Brausch

http://home.arcor.de/dreamlike
Nov 13 '05 #1
Share this Question
Share on Google+
140 Replies


P: n/a
"Oliver Brausch" <ob***@web.de> wrote in message
news:cd*************************@posting.google.co m...
have you ever heard about this MS-visual c compiler bug?
look at the small prog:
It is not a compiler bug. It is a bug in your code.
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. Microsoft's compiler is absolutely right.
void main(int argc, char **argv) {
'void main' is illegal. It is *always* 'int main'.
int i;
for (i = 0; i < 5; i++) printf("%d. %d\n", i, bit64());
} This is what every compiled progam says. Inclusive MSVisualC Compiler
with Debug options or /Ot fast-option.
So? Just because many compiled programs say this should be the result
does not mean that they are right.
Ever seen this? I costed me hours of debugging. Can I
sue Microsoft for this?


No, but your boss could fire you for such C code, since it is invalid.
--
jb

(replace y with x if you want to reply by e-mail)
Nov 13 '05 #2

P: n/a
Oliver Brausch <ob***@web.de> scribbled the following
on comp.lang.c:
Hello, have you ever heard about this MS-visual c compiler bug?
look at the small prog:
static int x=0;
int bit32() {
return ++x;
} int bit64() {
return bit32() + (bit32() << 1);
These two bit32() calls can be evaluated in either order, and the
implementation doesn't even have to be consistent about it.

Assume x==0. The first way:
bit32() + (bit32() << 1) ==
1 + (bit32() << 1) ==
1 + (2 << 1) ==
1 + (4) ==
5
The second way:
bit32() + (1 << 1) ==
bit32() + (2) ==
2 + (2) ==
4
} void main(int argc, char **argv) {
You have induced undefined behaviour by using void main() and lost all
right to expect any kind of specific behaviour at all.
int i;
for (i = 0; i < 5; i++) printf("%d. %d\n", i, bit64());
}
Ok, the (correct) result is:
Anything. Any result is correct, because of the void main().
0. 2
1. 8
2. 14
3. 20
4. 26 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
You'll have to read up on undefined behaviour (void main()) and
unspecified behaviour (bit32() + (bit32() << 1)).
So, up to Microsoft, 0 + 2 = 1 ?????. That's why their OS is so stable....
Try to increase the "<< 1". It even gets worse. Ever seen this? I costed me hours of debugging. Can I
sue Microsoft for this?


No. It's neither their or C's fault. It's yours.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"There's no business like slow business."
- Tailgunner
Nov 13 '05 #3

P: n/a
Oliver Brausch wrote:
Hello,

have you ever heard about this MS-visual c compiler bug?
Nope.
look at the small prog:
OK...
static int x=0;
int bit32() {
return ++x;
}

int bit64() {
return bit32() + (bit32() << 1);
}

void main(int argc, char **argv) { int main(int argc, char **argv) {

but since you're not making use of the command-line interface,

int main(void)

would do quite nicely...
int i;
for (i = 0; i < 5; i++) printf("%d. %d\n", i, bit64());
}
Ok, the (correct) result is:

0. 2
1. 8
2. 14
3. 20
4. 26
Oh, really?

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]

Please see: http://www.eskimo.com/~scs/C-faq/s3.html for an explanation.

Ever seen this? I costed me hours of debugging. Can I
sue Microsoft for this?


Actually, even if it had been their bug (which it isn't) you couldn't --
read the license.

HTH,
--ag

[1] Not that I would mind a bit had it been _their_ fault.

--
Artie Gold -- Austin, Texas

Nov 13 '05 #4

P: n/a
In article <bf*************@news.t-online.com>,
Jakob Bieling <ne*****@gmy.net> wrote:
"Oliver Brausch" <ob***@web.de> wrote in message
news:cd*************************@posting.google.c om...
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".)

-- Brett
Nov 13 '05 #5

P: n/a
Brett Frankenberger <rb*@panix.com> scribbled the following
on comp.lang.c:
In article <bf*************@news.t-online.com>,
Jakob Bieling <ne*****@gmy.net> wrote:
"Oliver Brausch" <ob***@web.de> wrote in message
news:cd*************************@posting.google. com...
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".

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"Life without ostriches is like coffee with milk."
- Mika P. Nieminen
Nov 13 '05 #6

P: n/a
In article <bf**********@oravannahka.helsinki.fi>,
Joona I Palaste <pa*****@cc.helsinki.fi> wrote:
Brett Frankenberger <rb*@panix.com> scribbled the following
on comp.lang.c:
In article <bf*************@news.t-online.com>,
Jakob Bieling <ne*****@gmy.net> wrote:
"Oliver Brausch" <ob***@web.de> wrote in message
news:cd*************************@posting.google .com...
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.


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.

-- Brett

Nov 13 '05 #7

P: n/a
On Sun, 20 Jul 2003 18:29:35 GMT, "Falcon Kirtarania" <cm****@shaw.ca>
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.

--
Be seeing you.
Nov 13 '05 #8

P: n/a
"Falcon Kirtarania" <cm****@shaw.ca> wrote in message
news:jc***********************@news1.calgary.shaw. ca...

"Jakob Bieling" <ne*****@gmy.net> wrote in message
news:bf*************@news.t-online.com...
"Oliver Brausch" <ob***@web.de> wrote in message
news:cd*************************@posting.google.co m...
have you ever heard about this MS-visual c compiler bug?
look at the small prog:


It is not a compiler bug. It is a bug in your code.
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. Microsoft's compiler is absolutely right.
void main(int argc, char **argv) {


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


You might want to do a search on Google about why you should write 'int
main' instead of 'void main'. Do not want to start such a long discussion
again. ;o)

regards
--
jb

(replace y with x if you want to reply by e-mail)
Nov 13 '05 #9

P: n/a
In article <cd*************************@posting.google.com> ,
ob***@web.de (Oliver Brausch) wrote:
Hello,

have you ever heard about this MS-visual c compiler bug?
look at the small prog:
static int x=0;
int bit32() {
return ++x;
}

int bit64() {
return bit32() + (bit32() << 1);
}

void main(int argc, char **argv) {
int i;
for (i = 0; i < 5; i++) printf("%d. %d\n", i, bit64());
}
Ok, the (correct) result is:

0. 2
1. 8
2. 14
3. 20
4. 26

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.

Ever seen this? I costed me hours of debugging. Can I
sue Microsoft for this?


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.
Nov 13 '05 #10

P: n/a
In 'comp.lang.c', ob***@web.de (Oliver Brausch) wrote:
have you ever heard about this MS-visual c compiler bug?
look at the small prog:

static int x=0;
int bit32() {
return ++x;
I don't like that too much.
}
Do you meant?

int bit32()
{
static int x=0;

x++;
return x;
}
int bit64() {
return bit32() + (bit32() << 1);
}
Let's go by hand:

[0] 1 + (2 * 2) = 5
[1] 3 + (4 * 2) = 11
[2] 5 + (6 * 2) = 17
[3] 7 + (8 * 2) = 23
[4] 9 + (10 * 2) = 29

Dev-C++ (gcc) :

0. 5
1. 11
2. 17
3. 23
4. 29
void main(int argc, char **argv) {
int i;
for (i = 0; i < 5; i++) printf("%d. %d\n", i, bit64());
}
Ok, the (correct) result is:

0. 2
1. 8
2. 14
3. 20
4. 26
Why?
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
Wrong too. Sounds like a UB. I suspect a sequence point is missing in
return ++x;

--
-ed- em**********@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Nov 13 '05 #11

P: n/a
Any compiler I've used never called it.

"Thore B. Karlsen" <si*@6581.com> wrote in message
news:5m********************************@4ax.com...
On Sun, 20 Jul 2003 18:29:35 GMT, "Falcon Kirtarania" <cm****@shaw.ca>
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.

--
Be seeing you.

Nov 13 '05 #12

P: n/a
Emmanuel Delahaye <em**********@noos.fr> scribbled the following
on comp.lang.c:
In 'comp.lang.c', ob***@web.de (Oliver Brausch) wrote:
have you ever heard about this MS-visual c compiler bug?
look at the small prog:

static int x=0;
int bit32() {
return ++x; I don't like that too much. } Do you meant? int bit32()
{
static int x=0; x++;
return x;
} int bit64() {
return bit32() + (bit32() << 1);
} Let's go by hand: [0] 1 + (2 * 2) = 5
[1] 3 + (4 * 2) = 11
[2] 5 + (6 * 2) = 17
[3] 7 + (8 * 2) = 23
[4] 9 + (10 * 2) = 29 Dev-C++ (gcc) : 0. 5
1. 11
2. 17
3. 23
4. 29 void main(int argc, char **argv) {
int i;
for (i = 0; i < 5; i++) printf("%d. %d\n", i, bit64());
}
Ok, the (correct) result is:

0. 2
1. 8
2. 14
3. 20
4. 26 Why?
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
Wrong too. Sounds like a UB. I suspect a sequence point is missing in

return ++x;


No, there is nothing wrong with "return ++x;" by itself. Not a missing
sequence point, anyway. Others have already explained the OP's problems
to him: (1) He's using void main(), undefined behaviour. (2) He's
calling bit32() twice without an intervening sequence point,
unspecified behaviour.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"You can pick your friends, you can pick your nose, but you can't pick your
relatives."
- MAD Magazine
Nov 13 '05 #13

P: n/a
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.

Still, I am stuck wondering why this is taking place in r.g.c.c

NR

Nov 13 '05 #14

P: n/a
Falcon Kirtarania <cm****@shaw.ca> 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" <si*@6581.com> wrote in message
news:5m********************************@4ax.com...
On Sun, 20 Jul 2003 18:29:35 GMT, "Falcon Kirtarania" <cm****@shaw.ca>
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.


--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"I will never display my bum in public again."
- Homer Simpson
Nov 13 '05 #15

P: n/a
On Sun, 20 Jul 2003 19:19:34 GMT, "Falcon Kirtarania" <cm****@shaw.ca>
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.
Nov 13 '05 #16

P: n/a
On 20 Jul 2003 10:14:53 -0700, ob***@web.de (Oliver Brausch) wrote:
<snip>

Ever seen this? I costed me hours of debugging.

<snip>


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

Nov 13 '05 #17

P: n/a
Perhaps not in ISO C, then. Whatever. As long as you don't need to port it
between compilers, it really doesn't matter.

"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:bf**********@oravannahka.helsinki.fi...
Falcon Kirtarania <cm****@shaw.ca> 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" <si*@6581.com> wrote in message
news:5m********************************@4ax.com...
On Sun, 20 Jul 2003 18:29:35 GMT, "Falcon Kirtarania" <cm****@shaw.ca>
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.


--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"I will never display my bum in public again."
- Homer Simpson

Nov 13 '05 #18

P: n/a
It does, as long as you are considering only the standards of those
compilers.

"Thore B. Karlsen" <si*@6581.com> wrote in message
news:j7********************************@4ax.com...
On Sun, 20 Jul 2003 19:19:34 GMT, "Falcon Kirtarania" <cm****@shaw.ca>
wrote:
Yes, but it is still legal, in that it will compile. I am not saying voidmain 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 crapabout certain results.


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

--
Be seeing you.

Nov 13 '05 #19

P: n/a
"Falcon Kirtarania" <cm****@shaw.ca> wrote:
Yes, but it is still legal, in that it will compile.
'it will compile' and 'it is legal C or C++' are two different shoes.
I am not saying void
main should be considered good practice, only that it is still compilable


On the few compilers you have used, that might be true. It is also true
for the compiler I use. So what, it is still illegal.
--
jb

(replace y with x if you want to reply by e-mail)
Nov 13 '05 #20

P: n/a

"Falcon Kirtarania" <cm****@shaw.ca> wrote in message
news:bR***********************@news1.calgary.shaw. ca...
Perhaps not in ISO C, then. Whatever. As long as you don't need to port it between compilers, it really doesn't matter.


And then comes the time that you have to port it and it needs to be ready
yesterday. It will really make your life easier if you do the portable thing
from the beginning, especially if it doesn't take any extra effort like the
"int main" example. In the end it will make your life easier (and that from
others).
Nov 13 '05 #21

P: n/a
Falcon Kirtarania wrote:
It does, as long as you are considering only the standards of those
compilers.


Why this insistance on writing invalid C? Doesn't the
correct version work on your compiler?

It works driving 120mph on a road were the speed limit is
30 mph. Because the police is not out today...
--
Thomas.
"What is the future c existence which does not do in all languages"

Nov 13 '05 #22

P: n/a
On Sun, 20 Jul 2003 20:21:27 GMT, "Falcon Kirtarania" <cm****@shaw.ca>
wrote:
Perhaps not in ISO C, then. Whatever. As long as you don't need to port it
between compilers, it really doesn't matter.

Forgive me for interrupting but correct me if I'm wrong: are you
trying to make up excuses for not complying with the standards?
Nov 13 '05 #23

P: n/a
On Sun, 20 Jul 2003 20:22:21 GMT, "Falcon Kirtarania" <cm****@shaw.ca>
wrote:
It does, as long as you are considering only the standards of those
compilers.


Well, now you are just being silly.
Nov 13 '05 #24

P: n/a
In article <9h********************************@4ax.com>,
ig**********************************...* **@mail.com says...
On Sun, 20 Jul 2003 20:21:27 GMT, "Falcon Kirtarania" <cm****@shaw.ca>
wrote:
Perhaps not in ISO C, then. Whatever. As long as you don't need to port it
between compilers, it really doesn't matter.

Forgive me for interrupting but correct me if I'm wrong: are you
trying to make up excuses for not complying with the standards?


Looks like it. Getting int main correct is so simple that anyone
refusing to abide by it should be fired anyway.

--
Randy Howard
(remove the obvious bits from my address to reply.)
"Most of the drivers nowadays are a bit like Eddie Irvine, who if
he was half as fast as he thought he was, would be moderate."
-- Sir Stirling Moss
Nov 13 '05 #25

P: n/a
In article <1S***********************@news3.calgary.shaw.ca >,
cm****@shaw.ca says...
It does, as long as you are considering only the standards of those
compilers.


Are you really this clueless, or just a troll? Compilers do not
define or express (recognized) standards by themselves. If you
want to claim "I write in standard Microsoft Visual C/C++ 6.0",
whatever that gibberish might imply, fine. Nobody should hire
you if that's your position however.

The "void main()" silliness got kick-started into heavy incorrect
use BECAUSE of the stupidity of the Microsoft C compiler and its
sample code along time ago. This, followed by some incredibly
bad books on the language by Schildt and his ilk just made it worse.
--
Randy Howard
(remove the obvious bits from my address to reply.)
"Most of the drivers nowadays are a bit like Eddie Irvine, who if
he was half as fast as he thought he was, would be moderate."
-- Sir Stirling Moss
Nov 13 '05 #26

P: n/a
Yes, but since we really don't port main very much, I really don't see the
point. The only reason to do that is if you tend to reuse virtually the
same code and make versions over a long period of time. Which also brings
to a head; what trouble is it to change void to int and say "return 0" at
the end, when it is time to port? I am sure almost everyone would notice if
the void main was the problem.

"Serve Laurijssen" <ik@thuis.nl> wrote in message
news:bf**********@news4.tilbu1.nb.home.nl...

"Falcon Kirtarania" <cm****@shaw.ca> wrote in message
news:bR***********************@news1.calgary.shaw. ca...
Perhaps not in ISO C, then. Whatever. As long as you don't need to
port it
between compilers, it really doesn't matter.
And then comes the time that you have to port it and it needs to be ready
yesterday. It will really make your life easier if you do the portable

thing from the beginning, especially if it doesn't take any extra effort like the "int main" example. In the end it will make your life easier (and that from others).

Nov 13 '05 #27

P: n/a
Randy Howard <ra**********@foomegapathdslbar.net> scribbled the following
on comp.lang.c:
In article <1S***********************@news3.calgary.shaw.ca >,
cm****@shaw.ca says...
It does, as long as you are considering only the standards of those
compilers.
Are you really this clueless, or just a troll? Compilers do not
define or express (recognized) standards by themselves. If you
want to claim "I write in standard Microsoft Visual C/C++ 6.0",
whatever that gibberish might imply, fine. Nobody should hire
you if that's your position however. The "void main()" silliness got kick-started into heavy incorrect
use BECAUSE of the stupidity of the Microsoft C compiler and its
sample code along time ago. This, followed by some incredibly
bad books on the language by Schildt and his ilk just made it worse.


Come to think of it, has anyone ever expressed a reason for using void
main() instead of int main()? Whatever reason could there be?
"It works on more compilers." False. It actually works on less.
"You don't have to return a value." You don't have to return a value
from int main() either in some standards, and when you do, you can
safely always return 0.
"It saves typing." Since when does a 4-letter keyword save typing more
than a 3-letter one?
"Microsoft does it." If Microsoft jumped off the Grand Canyon, would
you follow them?
"Following standards is for sissies." Well... =)

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"And according to Occam's Toothbrush, we only need to optimise the most frequent
instructions."
- Teemu Kerola
Nov 13 '05 #28

P: n/a
But all I am saying is not that it is good syntax, just that it is not
absolutely necessary.

"Randy Howard" <ra**********@FOOmegapathdslBAR.net> wrote in message
news:MP************************@news.megapathdsl.n et...
In article <9h********************************@4ax.com>,
ig**********************************...* **@mail.com says...
On Sun, 20 Jul 2003 20:21:27 GMT, "Falcon Kirtarania" <cm****@shaw.ca>
wrote:
Perhaps not in ISO C, then. Whatever. As long as you don't need to port itbetween compilers, it really doesn't matter.

Forgive me for interrupting but correct me if I'm wrong: are you
trying to make up excuses for not complying with the standards?


Looks like it. Getting int main correct is so simple that anyone
refusing to abide by it should be fired anyway.

--
Randy Howard
(remove the obvious bits from my address to reply.)
"Most of the drivers nowadays are a bit like Eddie Irvine, who if
he was half as fast as he thought he was, would be moderate."
-- Sir Stirling Moss

Nov 13 '05 #29

P: n/a
Falcon Kirtarania <cm****@shaw.ca> scribbled the following
on comp.lang.c:
Yes, but since we really don't port main very much, I really don't see the
point. The only reason to do that is if you tend to reuse virtually the
same code and make versions over a long period of time. Which also brings
to a head; what trouble is it to change void to int and say "return 0" at
the end, when it is time to port? I am sure almost everyone would notice if
the void main was the problem.


If it isn't so much trouble to change void to int and say "return 0",
then why don't you do it? What do you gain by being gratuitously non-
standard? Are you some sort of rebel coder?

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"And according to Occam's Toothbrush, we only need to optimise the most frequent
instructions."
- Teemu Kerola
Nov 13 '05 #30

P: n/a
Fine, I admit to being a bit of a troll that time.

"Randy Howard" <ra**********@FOOmegapathdslBAR.net> wrote in message
news:MP************************@news.megapathdsl.n et...
In article <1S***********************@news3.calgary.shaw.ca >,
cm****@shaw.ca says...
It does, as long as you are considering only the standards of those
compilers.


Are you really this clueless, or just a troll? Compilers do not
define or express (recognized) standards by themselves. If you
want to claim "I write in standard Microsoft Visual C/C++ 6.0",
whatever that gibberish might imply, fine. Nobody should hire
you if that's your position however.

The "void main()" silliness got kick-started into heavy incorrect
use BECAUSE of the stupidity of the Microsoft C compiler and its
sample code along time ago. This, followed by some incredibly
bad books on the language by Schildt and his ilk just made it worse.
--
Randy Howard
(remove the obvious bits from my address to reply.)
"Most of the drivers nowadays are a bit like Eddie Irvine, who if
he was half as fast as he thought he was, would be moderate."
-- Sir Stirling Moss

Nov 13 '05 #31

P: n/a
I am just pointing out something in logic, just to be a troll.

"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:bf**********@oravannahka.helsinki.fi...
Falcon Kirtarania <cm****@shaw.ca> scribbled the following
on comp.lang.c:
Yes, but since we really don't port main very much, I really don't see the point. The only reason to do that is if you tend to reuse virtually the
same code and make versions over a long period of time. Which also brings to a head; what trouble is it to change void to int and say "return 0" at the end, when it is time to port? I am sure almost everyone would notice if the void main was the problem.
If it isn't so much trouble to change void to int and say "return 0",
then why don't you do it? What do you gain by being gratuitously non-
standard? Are you some sort of rebel coder?

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"And according to Occam's Toothbrush, we only need to optimise the most

frequent instructions."
- Teemu Kerola

Nov 13 '05 #32

P: n/a
In article <Jg***********************@news3.calgary.shaw.ca >,
cm****@shaw.ca says...
But all I am saying is not that it is good syntax, just that it is not
absolutely necessary.


Ridiculous. It *IS* absolutely necessary if you don't want to be
taken by a fool. The standard says main ALWAYS returns int. Just
because you happen to have a broken compiler doesn't make it "not
absolutely necessary".

--
Randy Howard
(remove the obvious bits from my address to reply.)
Nov 13 '05 #33

P: n/a
"Falcon Kirtarania" <cm****@shaw.ca> wrote in message
news:7e***********************@news3.calgary.shaw. ca...
Yes, but since we really don't port main very much, I really don't see the
point. The only reason to do that is if you tend to reuse virtually the
same code and make versions over a long period of time. Which also brings
to a head; what trouble is it to change void to int and say "return 0" at
the end, when it is time to port?


You do not have to write 'return 0;' (at least in C++ .. but I assume it
is the same in C). So you see, you actually have to write *less* code to get
correct code! So why do you bother typin 'void', if you could just type
'int'??

Also, the reason 'we don't port main very much' is a poor excuse to
write illegal code, don't you think?
--
jb

(replace y with x if you want to reply by e-mail)
Nov 13 '05 #34

P: n/a
In article <bf*************@news.t-online.com>,
"Jakob Bieling" <ne*****@gmy.net> wrote:
"Falcon Kirtarania" <cm****@shaw.ca> wrote in message
news:7e***********************@news3.calgary.shaw. ca...
Yes, but since we really don't port main very much, I really don't see the
point. The only reason to do that is if you tend to reuse virtually the
same code and make versions over a long period of time. Which also brings
to a head; what trouble is it to change void to int and say "return 0" at
the end, when it is time to port?


You do not have to write 'return 0;' (at least in C++ .. but I assume it
is the same in C). So you see, you actually have to write *less* code to get
correct code! So why do you bother typin 'void', if you could just type
'int'??

Also, the reason 'we don't port main very much' is a poor excuse to
write illegal code, don't you think?


If someone uses "void main" instead of "int main" then you get some idea
of their knowledge, and you can draw your conclusions from that. If they
insist that "void main" is correct then you also get some idea of their
attitude, and you can draw much more important conclusions from that.
Nov 13 '05 #35

P: n/a
"Falcon Kirtarania" <cm****@shaw.ca> wrote in message
news:Zw***********************@news2.calgary.shaw. ca...

"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:bf**********@oravannahka.helsinki.fi...
Falcon Kirtarania <cm****@shaw.ca> scribbled the following
on comp.lang.c:
No, I am stating that, in this case, the standard is not relevant
unless
you have an intention of porting. In fact, it may be hindering to comply with it, in such cases as two options in the fopen command provided in VS6.


We're not talking about fopen(). We're talking about void main() versus
int main(). Please tell me what reason you might possibly have for
choosing void main().


If you don't need to return an exit code?


Then don't?

int main ()
{
}

Is perfectly valid C and C++ code. No need to return an exit code.
--
jb

(replace y with x if you want to reply by e-mail)
Nov 13 '05 #36

P: n/a
Hello all,
let me first lose some words to all the nice respons.

For example,
"Jakob Bieling" <ne*****@gmy.net> wrote in message news:<bf*************@news.t-online.com>...
void main(int argc, char **argv) {
'void main' is illegal. It is *always* 'int main'.


Ah yes?! and what does this change to the PROBLEM I described?
I think, you (and other who do this discussion) lose the focus.
No, but your boss could fire you for such C code, since it is invalid.


I would rather fire somebody who always loses the focus instead of such
really nonimportant points. BTW, I always use int main() as you
can see in my programms. But for this example it is absolutely
irrelevant.

Some people claim that the result I wrote is not correct at all.
Of course, it was "return x++" instead and forgot it in the
posting. Another point, that is not important to the problem at all.

int bit64() {
return bit32() + (bit32() << 1);
}


You try to change a variable twice, which is invalid, ie. undefined
behaviour. Microsoft's compiler is absolutely right.


Ok, this is correct. I was of the opinion that such statements are
read from left to right. But it seems wrong, even most compilers
would do it like this. Ok, my fault, I learned it now (even
before reading all this flames.)

So thanks for the support.

Oliver
Nov 13 '05 #37

P: n/a
"Oliver Brausch" <ob***@web.de> wrote in message
news:cd*************************@posting.google.co m...
Hello all,
let me first lose some words to all the nice respons.

For example,
"Jakob Bieling" <ne*****@gmy.net> wrote in message news:<bf*************@news.t-online.com>...
void main(int argc, char **argv) {
'void main' is illegal. It is *always* 'int main'.


Ah yes?! and what does this change to the PROBLEM I described?
I think, you (and other who do this discussion) lose the focus.


No, because this might as well have been the source of your problem
after all.
No, but your boss could fire you for such C code, since it is

invalid.
I would rather fire somebody who always loses the focus instead of such
really nonimportant points. BTW, I always use int main() as you
can see in my programms. But for this example it is absolutely
irrelevant.


Again: it is not irrelevant. A program using 'void main' may produce any
behaviour.
--
jb

(replace y with x if you want to reply by e-mail)
Nov 13 '05 #38

P: n/a
Randy Howard wrote:
In article <Jg***********************@news3.calgary.shaw.ca >,
cm****@shaw.ca says...
But all I am saying is not that it is good syntax, just that it is not
absolutely necessary.


Ridiculous. It *IS* absolutely necessary if you don't want to be
taken by a fool.


Way too late.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #39

P: n/a
> Ok, this is correct. I was of the opinion that such statements are
read from left to right. But it seems wrong, even most compilers
would do it like this. Ok, my fault, I learned it now (even
before reading all this flames.)


"Would" is the proper word here - first thing I was thinking of that the
optimalization may cause the compiler to things in a different order. I am
not sure why that would be faster...

Martijn
Nov 13 '05 #40

P: n/a

"Falcon Kirtarania" <cm****@shaw.ca> wrote in message
news:ag***********************@news3.calgary.shaw. ca...
No, I am stating that, in this case, the standard is not relevant unless you have an intention of porting. In fact, it may be hindering to comply with
it, in such cases as two options in the fopen command provided in VS6.


fopen? Just use CreateFile(). It is the correct C syntax after all.
Nov 13 '05 #41

P: n/a
On Mon, 21 Jul 2003 14:49:31 +0200, "Serve Laurijssen" <ik@thuis.nl> wrote:

"Falcon Kirtarania" <cm****@shaw.ca> wrote in message
news:ag***********************@news3.calgary.shaw .ca...
No, I am stating that, in this case, the standard is not relevant unless

you
have an intention of porting. In fact, it may be hindering to comply with
it, in such cases as two options in the fopen command provided in VS6.


fopen? Just use CreateFile(). It is the correct C syntax after all.


Nope. CreateFile() is a Microsoft /extension/ to C, not part of C at all.

The correct /C/ function to create a file would be fopen().
--
Lew Pitcher
IT Consultant, Enterprise Technology Solutions
Toronto Dominion Bank Financial Group

(Opinions expressed are my own, not my employers')
Nov 13 '05 #42

P: n/a
Lew Pitcher <Le*********@td.com> scribbled the following
on comp.lang.c:
On Mon, 21 Jul 2003 14:49:31 +0200, "Serve Laurijssen" <ik@thuis.nl> wrote:
"Falcon Kirtarania" <cm****@shaw.ca> wrote in message
news:ag***********************@news3.calgary.sha w.ca...
No, I am stating that, in this case, the standard is not relevant unlessyou
have an intention of porting. In fact, it may be hindering to comply with
it, in such cases as two options in the fopen command provided in VS6.


fopen? Just use CreateFile(). It is the correct C syntax after all.

Nope. CreateFile() is a Microsoft /extension/ to C, not part of C at all. The correct /C/ function to create a file would be fopen().


Perhaps Serve was paroidying Falcon here?

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"O pointy birds, O pointy-pointy. Anoint my head, anointy-nointy."
- Dr. Michael Hfuhruhurr
Nov 13 '05 #43

P: n/a
"Jakob Bieling" <ne*****@gmy.net> wrote in message
news:bf*************@news.t-online.com...

Then don't?

int main ()
{
}

Is perfectly valid C and C++ code. No need to return an exit code.


Funny enough, *that* code produces warnings in vc6 (complaining about the lack
of a return value). I've had that bite me a few times when I've used vc7 to
write code that will be compiled on vc6 for release.

VC7 and above do compile it silently.

Ken
Nov 13 '05 #44

P: n/a
>> fopen? Just use CreateFile(). It is the correct C syntax after all.

Nope. CreateFile() is a Microsoft /extension/ to C, not part of C at all.

The correct /C/ function to create a file would be fopen().


Dear Lew,

Welcome to Sarcasm, population 42. Don't get lost...

Nov 13 '05 #45

P: n/a
"Jakob Bieling" <ne*****@gmy.net> wrote in message news:<bf*************@news.t-online.com>...
"Falcon Kirtarania" <cm****@shaw.ca> wrote in message
news:Zw***********************@news2.calgary.shaw. ca...

"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:bf**********@oravannahka.helsinki.fi...
Falcon Kirtarania <cm****@shaw.ca> scribbled the following
on comp.lang.c:
> No, I am stating that, in this case, the standard is not relevant unless
you > have an intention of porting. In fact, it may be hindering to comply with > it, in such cases as two options in the fopen command provided in VS6.

We're not talking about fopen(). We're talking about void main() versus
int main(). Please tell me what reason you might possibly have for
choosing void main().


If you don't need to return an exit code?


Then don't?

int main ()
{
}

Is perfectly valid C and C++ code. No need to return an exit code.


I do not agree at all with Falcon's reasonment, but I must say that I
have always found this point in the standard crazy : What's this
function whose return type is int but where you do not need a "return"
statement? Why should main be an exception to the common, logical,
language rule? This is one of the few points in the standard where you
feel the result of ugly political disputs within the commitee, I
guess.

Also antoher point : I have never understood why so much people seems
to take the "void versus unt main" debate so religiously : it seems to
me rather unimportant and have very few impact on the semantic of the
language, so why does everybody consider this point so important?

Arnaud
MVP - VC
Nov 13 '05 #46

P: n/a
On Mon, 21 Jul 2003, Richard Bos wrote:
ad******@club-internet.fr (Arnaud Debaene) wrote:
language, so why does everybody consider this point so important?


My take on the matter is that it's similar to the its/it's difference in
English: it isn't all that important in itself, but if people get such


Well, there's a fairly clear logical reason for the its/it's
distinction (beyond just "follow the standard, Stupid!", which is an
important reason in general but leaves me with a desire for more
justification in some cases) *Its* is a possessive pronoun; pronouns
never form possessives by adding *'s*. Using *it's* as a possessive
pronoun is similar to using *he's* or *she's* or *him's* instead of *his*
or *her*. *It's* (properly used) is a conjunction of it and is. Using
*its* as a conjunction would be like using hes or shes instead of *he's*
or *she's*. (I've used * as a delimiter here since quotes may look
confusing with all the apostrophes...)

So anotherwords:

"Hes running" should be "He's running" (or "He is running" if you don't
like conjunctions in formal writing!)
"Its running" should be "It's running"
"He's property" should be "His property"
"It's property" should be "Its property"

Obviously common usage has made it's and its interchangable in many
cases; from the POV that it's OK as long as your point is clear, this is
fine. From the POV that you wish to score a perfect 100% on your
English exam, or impress everyone with your composition, this isn't fine.
I might bend this rule in hasty informal writing - not b/c of laziness or
apathy but simply b/c of human error. Otherwise IMHO, the sloppiness of
"hes" instead of "his", which seems parallel to and more obvious than
its/it's, indicates that correct usage important in all of these cases.

Getting back to programming - I definitely see many reasons why I would
use int instead of void for main:

- "Follow the standard, Stupid!"
- It's correct to use int
- It's no harder to use int than main
- Cross compiler compatibility
- I live in fear of vast pillars of flame chasing me around usenet, god
help me please save me from the flames

For these reasons I use int main (or would if I still used C!).
However, it would be nice to hear a purely logical reason (the above
all seem to be somewhat practical in nature) for this part of the standard
The best logical reason I've read so far in this thread is to support
example code from K&R, which is certainly practical but not 100% logical
reasoning. (i.e. something more along the lines of "possessive pronoun vs
conjunction" instead of "you're next english professor might fail you
even if your current one doesn't".) If no totally persuasive
logical reason exists, the above reasons are all sufficient anyway, IMO.

Dave

Nov 13 '05 #47

P: n/a
Ken Alverson wrote:
"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:3f****************@news.nl.net...

Then VC7 is at least partially C99 compatible, and VC6 is not. C89
required an explicit exit value, either from exit() or from a return
in main(); C99 allows (brokenly and pandering to laziness, IMO) the
lack of return statement (and will default to 0).


I don't think laziness is the reason behind the implied "return 0;"
for main, I think it's the irrational desire that the original K&R C
sample code compile without modification. I think the same reasoning
is what kept implied "int" around as well.

Ken


I've heard that another possible reason is to avoid warnings about
unreachable code paths in programs that are supposed to run forever and
never exit (e.g. daemons):

int main() {
for (;;) {
// do something - never break
}
return 0; // <--- Warning: Unused code
}

IMHO this "int vs. void" thing is really not worth arguing about.
Nobody's 100% compliant ;)
Nov 13 '05 #48

P: n/a
In article <16**************************@posting.google.com >,
ad******@club-internet.fr (Arnaud Debaene) wrote:
Also antoher point : I have never understood why so much people seems
to take the "void versus unt main" debate so religiously : it seems to
me rather unimportant and have very few impact on the semantic of the
language, so why does everybody consider this point so important?


It usually shows something about people's attitude. It is on many
implementations not a big problem, but it is absolutely trivial to do it
right. If someone is not willing to do it right, then I must conclude
that their attitude will not allow them to write good, clean code.
Nov 13 '05 #49

P: n/a
or _open, if you are not wanting to use formatted output.

"Lew Pitcher" <Le*********@td.com> wrote in message
news:3f**************@news21.on.aibn.com...
On Mon, 21 Jul 2003 14:49:31 +0200, "Serve Laurijssen" <ik@thuis.nl> wrote:

"Falcon Kirtarania" <cm****@shaw.ca> wrote in message
news:ag***********************@news3.calgary.shaw .ca...
No, I am stating that, in this case, the standard is not relevant unless
you
have an intention of porting. In fact, it may be hindering to comply

with it, in such cases as two options in the fopen command provided in VS6.


fopen? Just use CreateFile(). It is the correct C syntax after all.


Nope. CreateFile() is a Microsoft /extension/ to C, not part of C at all.

The correct /C/ function to create a file would be fopen().
--
Lew Pitcher
IT Consultant, Enterprise Technology Solutions
Toronto Dominion Bank Financial Group

(Opinions expressed are my own, not my employers')

Nov 13 '05 #50

140 Replies

This discussion thread is closed

Replies have been disabled for this discussion.