Horrible Visual C Bug!

[Serve Laurijssen]

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.

 

[Lew Pitcher]

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

 

[Joona I Palaste]

Lew Pitcher <[email protected]> scribbled the following

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 ([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! ------------/
"O pointy birds, O pointy-pointy. Anoint my head, anointy-nointy."
- Dr. Michael Hfuhruhurr

 

[Ken Alverson]

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

 

[Shill]

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

 

[Richard Bos]

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.

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

Richard

 

[Arnaud Debaene]

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

 

[Richard Bos]

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?

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
details wrong too often, it's a sign that they don't give a shit about
getting it right. IOW, if they can't even get these simple details
correctly, why should I trust them on the harder issues?

Richard

 

[Don Porges]

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 thing is, when you port a "void main()" program to an implementation where it really
matters that you use "int main()", you may well not get a message telling you to change your
source. One of two things is likely to happen:

your program will go wrong at the start of main;
your program will go wrong at the end of main, upon returning to the implementation's pre-main startup.

And either way, you'll be back here complaining about a "bug" in your new implementation's compiler.

 

[Jakob Bieling]

"Jakob Bieling" <[email protected]> wrote in message

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.

Well, if it were logical all the way, you would be complaining that you
always have to do a 'return 0' even though you do not care about the return
value. I agree that exceptions to rules in the language should be avoided,
but on the other hand I welcome the descision for an implicit 'return 0' in
main.

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?

Because it might hit you badly later, so what is wrong with writing
'int' instead of 'void' in the first place. Second, people who do not give
much about /that/ rule, will not give much about other 'little' rules and
soon we have crappy C and C++ code all over.

I think it gets sort of religious, simply because people try to make
illegal code legal, by using ridiculous arguments. Let alone the fact that
it is 'wrong', it bugs me that people try to argument 'for' it, which is why
I debate against it.

regards

 

[Ken Alverson]

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

 

[Dave C.]

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

 

[Elias Fotinis]

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

 

[Christian Bau]

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.

 

[Falcon Kirtarania]

or _open, if you are not wanting to use formatted output.

 

[Matti Vuori]

(e-mail address removed) (Lew Pitcher) wrote in

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

I wouldn't call it an "extension to C" -- it is just an OS API function,
nothing more.

 

[Kevin Easton]

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

On some architectures, the calling convention requires that the caller
know the return type of the callee to create correct code before and/or
after the function call.

In this case, the caller of main is deep inside some startup code that's
linked into every C executable you create - the only way it can know the
return type of the callee is if that return type is fixed. The reason
it's fixed as "int" and not "void" is so that the program has a simple
mechanism for telling the operating system whether it succeeded or
failed.

- Kevin.

 

[Charlie Gibbs]

Emmanuel Delahaye <[email protected]> scribbled the following



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.

A little voice inside my head starts screaming "Side effects!"
whenever I see something like this. My solution is simple:
don't do it.

"You can pick your friends, you can pick your nose, but you can't pick
your relatives."
- MAD Magazine

"You can smoke beef, and you can smoke hash, but you can't smoke
corned beef hash." -- National Lampoon

 

[Anthony Giorgianni]

An interjection from an interloper: 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 - almost poetic - if one fails to
comprehend the information to even the slightest degree. And since I excel
in this lack of comprehension and since I am reading this in the
rec.game.chess.computer newsgroup, it furthermore seems perfectly reasonable
for me to assume there is an equally incomprehensible connection to chess
and chess programming. So I am being thoroughly satisfied and entertained
all around.

Carry on )

--
Regards,
Anthony Giorgianni

(I prefer that you reply by posting back to the newsgroup. If you must
email: remove "killspam" from reply address. This email address will be
valid for a short time only.)

 

[Bob Hairgrove]

Then don't?

int main ()
{
}

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

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?