Horrible Visual C Bug!

[Joona I Palaste]

Bob Hairgrove <[email protected]> scribbled the following

Yes, but the trouble is how returning an "int" is usually implemented
in assembler (on Intel platforms, at least): the value in the EAX
register is read as the returned value.

If you don't specify a return value, EAX could contain anything at
all. If the calling process doesn't expect a return value, then it's
OK, but do you always know who (or what) will call your program?

I am not sure about this, but if the C and C++ standards say that is
valid C code, then they also specify a reasonable behaviour for it.
AFAIK not returning anything from main() is the same as returning 0.
The standards certainly don't specify anything about all this "EAX"
rubbish you're on about.

--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"Last year he disrespected me - and then he showed lack of respect."
- Anthony Mason

 

[Brett Frankenberger]

Yes, but the trouble is how returning an "int" is usually implemented
in assembler (on Intel platforms, at least): the value in the EAX
register is read as the returned value.

If you don't specify a return value, EAX could contain anything at
all. If the calling process doesn't expect a return value, then it's
OK, but do you always know who (or what) will call your program?

C99 specifies that if no return value is specified, then 0 must be
returned. If a particular implementation uses a calling convention
that the return value in in EAX, than that implementation needs to make
sure that, in the case of main, if it gets to the end of the function,
0 is loaded into EAX.

-- Brett

 

[jemma]

An interjection from an interloper:

Not at all.

The sad thing for all of you participating in this thread is that you'll never know
the sheer joy of seeing how cryptically fascinating it is...

Perhaps you're right, on the other hand the multi-level irony of the
entire thread is not lost on me. From the subject line, to the
multiple coding and posting errors, the actual sage advice, though the
petty bickering, and not least the cross-posted group selection, this
one's a dandy.

it furthermore seems perfectly reasonable for me to assume there is an equally
incomprehensible connection to chess and chess programming.

If so, it eludes me.


-Jemma

 

[Charlie Gibbs]

<[email protected]>

Yep. I even knew that. My mind must have been preoccupied with greater
manners. Yeah, that's it. I was solving hunger and implementing world
peace, so all these words that begin with 'c' blend together.

Believe it or not, at one point earlier in life I was able to pass
Latin grammar exams with high scores. Now I can't even explain my
native tongue. Soon I'll be sitting in my room counting shiny objects.

Dave 'OOH OOH SHINY!!! YAY!'

You mean you're going to give up programming and become a user?

Computing haiku:

Welcome to the world
Of point-and-drool computing
Apple Macintosh

(I suppose you could substitute "Windows 98" for the last line...)

 

[Christian Bau]

Yes, but the trouble is how returning an "int" is usually implemented
in assembler (on Intel platforms, at least): the value in the EAX
register is read as the returned value.

If you don't specify a return value, EAX could contain anything at
all. If the calling process doesn't expect a return value, then it's
OK, but do you always know who (or what) will call your program?

In that case your C compiler is broken. Both in C++ and in C99, a main
function without a return statement behaves exactly as if you wrote
"return 0; " as the last statement of the function. So the compiler
_must_ check that the function being compiled is the "main" function and
do the right thing.

 

[Guest]

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

The reason why the final program may do thing in a different order is that
it
has changed C instrucions into assembler instructions. At that level a lot
of
optimalizations are about: instruction wait states, instruction cache hit
prediction, data cache hit prediction, instruction pipelines efficiency, RAM
access wait states and so on. The optimizer re-orders instructions to take
some or all of the variables above into account, to create faster and/or
smaller code. Sometimes the optimizer do the wrong thing (even though it is
designed not to) and produces wrong results. However in this case there is
no
correct result since the C standard does not specify what the result should
be.

I am not an CPU expert or even assembler programmer, so some of the
information
may be wrongly stated, but it should explain (in a very general way) why
things
may be done in a different order than how it is read by a human in the C
source.

Roald

 

[Mark Gordon]

[Followups set to comp.lang.c]

Yes, but since we really don't port main very much, I really don't
see the point.

Maybe you don't port main very much. In fact, it's fairly obvious you
don't. But "we"? I move entire C programs, including main, between
compilers and OSs fairly regularly, and I doubt very much whether I'm
unusual in that regard.

You're not. I have a few programs that I regularly build for three
flavours of *nix and Windows 2000. In fact, I spend most of my time at
work on these programs.

What trouble is it to write the code properly in the first place?

Especially as it can make debugging easier since you can try to find the
problem using whichever environment gives you the best tools.

 

[Mr. Berserker]

<snip>

Just stop using shit M$ products and grab gcc...

 

[Kevin Handy]

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.

The 'void main' is usually just the tip of the iceberg. It does
serve well as a "clueless-newbie" alert.

When you see that, you can usually assume that it will probably
be eadier to re-write the program from scratch than to find all
the stupid "clueless-newbie" code that will be scattered
throughout the entire program.

Things like using differing parameters (both number and type)
between where a function is defined and where it is called,
pointer<->integer conversions, modifying variables multiple
times in one sequence point, cute tricks (like xor to swap
values), "optimizations" that are slower than normal code,
etc.

You see several of these, and you are almost guaranteed
to have a "void main".

 

[Joona I Palaste]

Mr. Berserker <[email protected]> scribbled the following

<snip>

Just stop using shit M$ products and grab gcc...

Did you READ any of the messages in this thread? The problem is with
the OP's code, not with any Microsoft product. Sheesh, some people...

--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"Immanuel Kant but Genghis Khan."
- The Official Graffitist's Handbook

 

[Arthur J. O'Dwyer]

You really have to be extremely anal to actually debate this. I would never
do any of the errors you mention up there but I regularily and blantatly use
void main(void) because it works just fine in all compilers I've used so
far.

"I am not a clueless newbie! How dare you suggest such a thing?!"

 

[Richard Heathfield]

Sin wrote:

You really have to be extremely anal to actually debate this.

So you thought void main was correct, and your current compiler didn't
disabuse you of the notion.

I would
never do any of the errors you mention up there

Why should we believe that? You can't even get main() right. How do you
expect to get anything /complicated/ right?

but I regularily and
blantatly use void main(void) because it works just fine in all compilers
I've used so far.

"Someone told me you can't hold the ball and run around the court in
basketball, but I tried it and it works fine. He obviously doesn't know
anything about basketball."

Unless I specifically need to return something to the
shell/OS, I don't bother.

It's not your decision to make.

As for the ansi standard, I don't give a rat's
ass about it,

So you wouldn't have any objection, then, if Microsoft suddenly decided to
change the behaviour of sqrt() without consulting you or even informing
you?

Conformance to a published standard is a guarantee for *you*, about the way
in which C programs will work, provided your code is written in accordance
with that standard.

the guys who make the compilers should be the ones working
on fixing them if they are not standard.

The onus is on you to get the return type of main() right. If you don't, the
behaviour is undefined.

Bad programming? I don't think so...

Your credibility as a judge of what constitutes bad programming has taken a
serious knock during this thread.

As long as you know what the
implications are (ie : at worse 2.5 seconds to change it if your program
ever sees the day it's ported to an anal compiler).

The implications are that your program's behaviour is undefined (and
therefore unconstrained - if it trashed your hard disk, for instance, you'd
have no comeback against the compiler vendor) and that, if you were hired
as a C programmer, you could well be sacked for incompetence if your
project manager were ever replaced by a real C expert.

 

[Sin]

WHY? *WHY*? Why in the name of all that's holy, do you *blatantly* use

void main()? *This* is what I've never understood. Do you really think
it's somehow better than int main(), or are you just displaying your
"standards are for suckers" attitude?

It's just a habit (a bad one, from your point of view, a neutral one from
mine)... It has, in my opinion, an extremely negliable impact (if any). I
just don't see the point in making the effort of changing that habit, let
alone debating about it.

As has been said many times, you don't have to return a value from int
main() either, so you don't have to give a rat's ass about it.

I might not be anal about the ansi standard but there's one thing I hate
above all : warnings... The compilers I work with give a warning when no
return type is used with main.

I think creating problems that can be solved in 2.5 seconds, when they
could have been avoided in the first place in 0.25 seconds, is bad
programming.

I just don't see it as a problem. It's only a problem if you need to port
the code to an anal compiler. And a problem so small that it's not a
problem.

Alex.

 

[Ron Natalie]

I might not be anal about the ansi standard but there's one thing I hate
above all : warnings... The compilers I work with give a warning when no
return type is used with main.

So return something. Nobody said you had to make use of the stupid-assed
feature that exempts you from having to return a value.

I just don't see it as a problem. It's only a problem if you need to port
the code to an anal compiler. And a problem so small that it's not a
problem.

You equate anal with standards conforming?

 

[Mark McIntyre]

Compilers... I use vc6, vc.net and watcom (under QNX). In fact, I've worked
with Borland too, and none of these ever complained about void main(void)...

Firstly they're not obliged to. Its worth noting that the C Standard
only requires compilers to complain about syntax errors and a couple
of other pretty major things. Bad code, noncompliant code, they can
accept silently but store up some nasties for later, or emit nonsense
messages "your hedgehog has been painted purple, compilation aborted",
or start playing "greensleeves" on your PC speaker.

Secondly, you should find that at least some of these /do/ complain if
you set warning levels to the max. Don't blame the compiler if you're
turning off warnings !!

Right, it's the compiler's job to make sure I abide to the syntax.

Correct. But this is NOT a syntax error.

And in any events its your job to write correct code. Do you expect
your car to stop you driving on the wrong side of the road? Or your
shotgun to prevent you from blowing your foot off?

Undefined in the ansi C standard... It is defined for the compilers who
provide this "rogue" functionality.

Well firstly, to be compliant with the ISO standard, main _must_
return an int. This is nonoptional.

And secondly, if void main() /is/ defined, the compiler writer is
obliged to document it. MS products do NOT document it, in fact the
reverse, they state that main must return an int. The fact that their
sample code doesn't do that is merely bad quality control.

Lets make a poll... How many poeple here have lost a job because they used
void main(void)?

Better idea: how many have failed a job interview becuase they didn't
know even this fundamental thing about C?

I have enough trust in the poeple who program these compilers that if they
went out of their way to provide void main(void) compilation, they insured
it would not trash anything.

Good luck

 

[Robert Hyatt]

<snip>

Just stop using shit M$ products and grab gcc...

It will do the same thing. C is C is C.

 

[Lucian Wischik]

The 'void main' is usually just the tip of the iceberg. It does
serve well as a "clueless-newbie" alert.
Things like using differing parameters... [snip]
You see several of these, and you are almost guaranteed
to have a "void main".

Your first point is a logical implication in the forward direction.
But your substantiation at the end is in the reverse direction.
Logical errors like these also serve well as a "clueless" alert...

 

[Richard Bos]

You really have to be extremely anal to actually debate this.

"I like insulting people."

I would never do any of the errors you mention up there but I
regularily and blantatly use void main(void)

"I can't get details right."

because it works just fine in all compilers I've used so far.

"I think the world consists of Losedows boxen."

As for the ansi standard, I don't give a rat's ass about it,

"I am arrogant."

Bad programming? I don't think so...

"Trust me."

I don't think so.

Richard

 

[Richard Heathfield]

Compilers... I use vc6, vc.net and watcom (under QNX). In fact, I've
worked with Borland too, and none of these ever complained about void
main(void)...

Switch on the conformance flag for Borland (-A) and you will find that
Borland refuses to compile a void main program.

Well I don't have anything to prove.

I agree entirely.

And I prefer complex things to
complicated things. To each his own.

Whichever you prefer, it makes sense to get the simple things right first.

Right, it's the compiler's job to make sure I abide to the syntax.

You really don't know this language, do you? It's not a syntax error, and
it's not a constraint violation. It's a violation of a "shall" clause
outside a constraint, and therefore the behaviour is undefined.

Undefined in the ansi C standard... It is defined for the compilers who
provide this "rogue" functionality.

Is it really? Quite a few people have looked for Microsoft's C documentation
of the effect of void main. I don't think anyone has found it yet.

Lets make a poll... How many poeple here have lost a job because they used
void main(void)?

Precious few, I should think, because most of us know that the return type
of main() is int.

I occasionally conduct recruitment interviews for C programmers. At such
interviews, I always ask the programmer what main() returns. If he gets the
answer wrong, which does sometimes happen, it is unlikely that he will get
the job.

I have enough trust in the poeple who program these compilers that if they
went out of their way to provide void main(void) compilation, they insured
it would not trash anything.

Really? Your faith is touching.

 

[Terence Hoosen]

The 'void main' is usually just the tip of the iceberg. It does serve
well as a "clueless-newbie" alert. Things like using differing
parameters... [snip] You see several of these, and you are almost
guaranteed to have a "void main".

Your first point is a logical implication in the forward direction. But
your substantiation at the end is in the reverse direction. Logical
errors like these also serve well as a "clueless" alert...

This is not the case. I believe he has reached his second conclusion by
the well practised process of induction (scientific, not mahemathical)
followed by a dose of abduction.

That such a conclusion is well founded or correct is what the OP and
like-minded individuals are arguing against. Of course, it is all in the
balance between standardisation and praxis.

-Tez