what is difference between sizeof and strlen

[pete]

Wouldn't it be more accurate to say it invokes implementation defined
behaviour?

No.
Every implementation need not document how void main is handled.

An example of implementation-defined behavior
is the propagation of the high-order bit when a signed
integer is shifted right.
Every implementation must document how that is handled.

 

[Keith Thompson]

Wouldn't it be more accurate to say it invokes implementation defined
behaviour?

Not really. The behavior of void main(), for example, is
implementation defined only if the implementation documents it. If a
non-standard declaration of main() is not specifically supported by
the implementation, the behavior is undefined (nasal demons and all
that).

 

[Anton Petrusevich]

^^^^
Why do so many people post without
c) learning the first thing about C from even the most basic textbook?

What if I do not care about the return value of the program? Or better, what
if I _do_ care but use exit(0)?

 

[Richard Bos]

What if I do not care about the return value of the program? Or better, what
if I _do_ care but use exit(0)?

Then you still haven't read the bleedin' FAQ.

Richard

 

[Flash Gordon]

What if I do not care about the return value of the program? Or better, what
if I _do_ care but use exit(0)?

Then you should still declare main as returning an int as that is the
only return type a hosted implementation is required to accept and
handle properly. Is it really so much work that declaring main properly
that you have to do something that might not work in some places instead?

 

[Martin Ambuhl]

Martin Ambuhl wrote:




What if I do not care about the return value of the program? Or better, what
if I _do_ care but use exit(0)?

The only thing that you might care about that is relevant is whether you
care that you have a program which is legal C. Your lack of concern
about the return value is immaterial.

 

[Anton Petrusevich]

Then you still haven't read the bleedin' FAQ.

Now I did. I am using C since 1989, and I have never had "a different
function call/return sequence, incompatible with what the caller (in main's
case, the C run-time startup code) expects". I am writing "int main()" of
cource, but I would really appreciate if someone could point me out the
system/compilator with such a strange behaviour.

 

[Lawrence Kirby]

What if I do not care about the return value of the program? Or better, what
if I _do_ care but use exit(0)?

By writing void main() your program has undefined behaviour even if it
never returns or exits at all. There is no guarantee that will even be
called successfully at program startup - you havn't provided a function
with a type that is compatible with what the implementation expects to
call.

Lawrence

 

[Keith Thompson]

Now I did. I am using C since 1989, and I have never had "a different
function call/return sequence, incompatible with what the caller (in main's
case, the C run-time startup code) expects". I am writing "int main()" of
cource, but I would really appreciate if someone could point me out the
system/compilator with such a strange behaviour.

Undefined behavior does not require any implementation to behave in
any particular manner. Even if every implementation in existence
handles void main() the way you expect it to, it's still undefined
behavior.

With void main() there's always the possibility that your program will
break under some future implementation, or even a current one. With
int main(void), you don't have to worry about that.

Even if the next platform you port your code to supports void main(),
you can't be sure that it does unless it's documented. When your
program misbehaves mysteriously, using int main(void) means there's
one less thing to worry about when you're tracking down the problem.

Some compilers issue a warning for void main().

With void main(), if you post your code here it's *guaranteed* that
people will jump down your throat about it.

 

[Anton Petrusevich]

By writing void main() your program has undefined behaviour even if it
never returns or exits at all. There is no guarantee that will even be
called successfully at program startup - you havn't provided a function
with a type that is compatible with what the implementation expects to
call.

2 variants: either it works or it does not. And only one of them will be
chosen on some particular system/compilator. I would not call it "undefined
behaviour", it's quite defined for a platform. And I just want to know the
name of the platform where it does not work. Could you enlighten me?

 

[Anton Petrusevich]

When your
program misbehaves mysteriously, using int main(void) means there's
one less thing to worry about when you're tracking down the problem.

As I understand it: run-time either calls void main() or it does not. It
can't be "mysterious", I see it as a "defined" behaviour.

With void main(), if you post your code here it's *guaranteed* that
people will jump down your throat about it.

Oh, yes, I see it now. I would call it "religious thing". I am not
religious, though I write "int main()" too. I just don't pay so big
attention to such things. I am a newbie in this conference and I am very
surprised seeing such a "religious thing" here.

 

[Richard Tobin]

I would not call it "undefined behaviour"

"Undefined behaviour" is a technical term in the C standard. It's not
really relevant whether *you* would call it that.

-- Richard

 

[Anton Petrusevich]

"Undefined behaviour" is a technical term in the C standard. It's not
really relevant whether *you* would call it that.

I don't get it. I thought, and I still continue to think, that "undefined
behaviour" means just that: when the behaviour is undefined. If the
behaviour is dependent on some defined thing (platform) then it's
"defined". You (or I) just need to know the platform. Of course, there's no
such (defined) thing as "platform" in C standard, so they say "undefined
behaviour". "int main()" is a tough religion, isn't it?

 

[Stephane Zuckerman]

"Undefined behaviour" is a technical term in the C standard. It's not

I don't get it. I thought, and I still continue to think, that "undefined
behaviour" means just that: when the behaviour is undefined. If the
behaviour is dependent on some defined thing (platform) then it's
"defined".

I think what you really missed is that this newsgroup is about ANSI/ISO C,
that is to say, C as a normalized language. Of course you are right : for
a given architecture, and a given compiler, the behaviour is predictable
to a certain extent. But then, we are not talking about portable C, or
ANSI C anymore. Let's go even further : is the behaviour of your compiler
documented ? If not, that means that it can change when the next version
comes out -- and that means modifying your code if you have to make it
compile with this brand new compiler, maybe forcing you to maintain two
slightly different versions of the same program.

You (or I) just need to know the platform. Of course, there's no
such (defined) thing as "platform" in C standard, so they say "undefined
behaviour". "int main()" is a tough religion, isn't it?

No, it is just the basis. If you allow yourself to write "void main()" out
of lazyness, what will you do with things that are really complicated ?

Lots and lots of C code can be made portable, hence helping you to avoid
rewriting too much code. This is truly a blessing (to stay with a
religious tone ;-)), and you should be happy this is so.

Once again, you are totally free to write non-standard C. This is just...
Not ANSI C, and therefore, not C, as the standard knows it.

 

[Richard Tobin]

I don't get it. I thought, and I still continue to think, that "undefined
behaviour" means just that: when the behaviour is undefined.

What the C standard means by it is that C standard places no
constraints on what will happen.

If the
behaviour is dependent on some defined thing (platform) then it's
"defined".

If the C standard requires the implementation to specify what will happen,
it's "implementation defined".

Of course, there's no
such (defined) thing as "platform" in C standard, so they say "undefined
behaviour".

There's also "implementation defined" as I mentioned above, but this
isn't a case of it.

-- Richard

 

[Anton Petrusevich]

Once again, you are totally free to write non-standard C. This is just...
Not ANSI C, and therefore, not C, as the standard knows it.

Thanks, this is the best answer

 

[Chris F.A. Johnson]

As I understand it: run-time either calls void main() or it does not. It
can't be "mysterious", I see it as a "defined" behaviour.


Oh, yes, I see it now. I would call it "religious thing". I am not
religious, though I write "int main()" too. I just don't pay so big
attention to such things. I am a newbie in this conference and I am very
surprised seeing such a "religious thing" here.

int main(void) is guaranteed to work.

void main() is not guaranteed to work.

What's religious about that?

 

[Keith Thompson]

As I understand it: run-time either calls void main() or it does not. It
can't be "mysterious", I see it as a "defined" behaviour.

You understand it incorrectly. The standard says that main shall
be defined with no parameters:
int main(void); /* or equivalent */
or with two parameters:
int main(int argc, char *argv[]); /* or equivalent */
or in some other implementation-defined manner. If an
implementation's documentation does not explicitly state that it
supports some other definition, then there is no "other
implementation-defined manner", and the two standard definitions are
the only ones allowed.

Since this is a "shall" requirement that's not part of a constraint,
violating it invokes undefined behavior.

A conforming implementation could reject "void main(void){}", or it
could cause it to behave in any perverse manner it chooses.

An implementation is allowed to support void main(void), but even
if it does, the following:

void main(void)
{
/* whatever */
}

is almost certainly equivalent to this:

int main(void)
{
/* whatever */
return 0;
}

and since the latter is portable, there is no advantage in using the
former.

Oh, yes, I see it now. I would call it "religious thing". I am not
religious, though I write "int main()" too. I just don't pay so big
attention to such things. I am a newbie in this conference and I am very
surprised seeing such a "religious thing" here.

There's nothing religious about it. It's a matter of correctness
about which there are strong feelings, largely because certain people
and/or institutions have encouraged something that is incorrect for no
good reason. Perhaps the word "religious" doesn't mean what you think
it means. (And if you want to discuss that further, please take it to
alt.usage.english.)

 

[Martin Ambuhl]

Oh, yes, I see it now.

No, you don't.

I would call it "religious thing".

Then you would be wrong. Using a language as it is defined is not
"religious." Insisting that using it in a way not allowed by its
definition is mystical, religious, and stupid. You have chosen the
wrong camp to label.

I am not
religious, though I write "int main()" too. I just don't pay so big
attention to such things.

No one should need to pay much attention. It is only when the most
basic aspect of writing correct programs is ignored that anyone pays
attention. When people start with the quasi-anarchist use of the word
"religious" for using a language as it is defined, people get pissed.

I am a newbie in this conference and I am very
surprised seeing such a "religious thing" here.

Get a clue.

 

[Martin Ambuhl]

"int main()" is a tough religion, isn't it?

How long are you going to keep this crap up? Soon your pseudo-anarchism
and childish name-calling will land you in multiple killfiles.