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

what is difference between sizeof and strlen

P: n/a
hello,
what is difference between sizeof("abcd") and strlen("abcd")? why
both functions gives different output when applied to same string
"abcd".
I tried following example for that.
#include <stdio.h>
#include <string.h>
void main()
{
char *str1="abcd";
char str2[]="abcd";
printf("%d %d %d",sizeof(str1),sizeof(str2),sizeof("abcd"));
printf("%d %d %d",strlen(str1),strlen(str2),strlen("abcd"));
}

Nov 15 '05 #1
Share this Question
Share on Google+
83 Replies


P: n/a

ra*******@gmail.com wrote:
hello,
what is difference between sizeof("abcd") and strlen("abcd")? why
1. Sizeof is an unary operator. Strlen is a function defined in
string.h.

2. Strlen looks for the first null('\0') and when found returns the
number
of characters that precede the null character.
both functions gives different output when applied to same string
See above. "abcd".
I tried following example for that.
#include <stdio.h>
#include <string.h>
void main() should be
int main() {
char *str1="abcd";
char str2[]="abcd"; Among other things, strlen() returns a size_t object, and you should
use
the `z' length modifier, followed by a conversion specifier d,i,o,u, x
or X.

Sizeof again yields the size of an object and using the specifier for
size_t
(and a cast, I'm not sure if required, before printing) should again be
preferred. printf("%d %d %d",sizeof(str1),sizeof(str2),sizeof("abcd"));
printf("%d %d %d",strlen(str1),strlen(str2),strlen("abcd"));
}


Do something like
char str[12];
strcpy(str, "hello");
printf("%zu vs %zu\n", DIM(str), strlen(str));
and you'll know.

Nov 15 '05 #2

P: n/a
ra*******@gmail.com wrote:
hello,
what is difference between sizeof("abcd") and strlen("abcd")? why
both functions gives different output when applied to same string
"abcd".
I tried following example for that.
#include <stdio.h>
#include <string.h>
void main()

^^^^
Why do so many people post without
a) following the newsgroup
b) checking the FAQ
or even
c) learning the first thing about C from even the most basic textbook?

It is impossible to take seriously a question from someone who could
screw up something so basic.
Nov 15 '05 #3

P: n/a
Martin Ambuhl wrote:
ra*******@gmail.com wrote:
hello,
what is difference between sizeof("abcd") and strlen("abcd")? why
both functions gives different output when applied to same string
"abcd".
I tried following example for that.
#include <stdio.h>
#include <string.h>
void main()

^^^^
Why do so many people post without
a) following the newsgroup
b) checking the FAQ
or even
c) learning the first thing about C from even the most basic textbook?

It is impossible to take seriously a question from someone who could
screw up something so basic.


Indeed it is possible. Most compilers won't issue a warning if you set
the return type to void. They will silently insert code to return a 0
and just go on.

Nov 15 '05 #4

P: n/a

ra*******@gmail.com wrote:
hello,
what is difference between sizeof("abcd") and strlen("abcd")? why
both functions gives different output when applied to same string
"abcd".
I tried following example for that.
#include <stdio.h>
#include <string.h>
void main()
{
char *str1="abcd";
char str2[]="abcd";
printf("%d %d %d",sizeof(str1),sizeof(str2),sizeof("abcd"));
printf("%d %d %d",strlen(str1),strlen(str2),strlen("abcd"));
}


sizeof is an operator and strlen is a C library function.
sizeof gives the size in bytes of its operand. size is determined
by the type of operand.
"abcd" is a string literal and its size is 5.
So, sizeof("abcd") = 5.
strlen("abcd") = 4. It does not include the terminating null character.

sizeof(str1) --> The operand str1 is a pointer to char. So, its type
is char pointer and size will be the size of char
pointer.
sizeof(str2) --> str2 is an array of characters. Standard C says
that "sizeof operator When applied to an operand
that has array type, the result is the total number
of bytes in the array. So, sizeof(str2) = 5.

sizeof("abcd") = 5.

strlen(str1) = 4.
strlen(str2) = 4.
strlen("abcd") = 4.

Nov 15 '05 #5

P: n/a
ra*******@gmail.com wrote:

hello,
what is difference between sizeof("abcd") and strlen("abcd")?


(sizeof("abcd") - strlen("abcd") == 1)

--
pete
Nov 15 '05 #6

P: n/a
Hi Rahul,

First of all, sizeof() and strlen() are differnt. The sizeof() is an
operator which gives the number of bytes required to store an object of
the type of it's operand and the strlen() is a function which takes a
constant string as an input and returns length of it's argument string.

If a constant string "abcd" is passed then strlen() will always return
4.
printf("%d %d %d",sizeof(str1),sizeof(str2),sizeof("abcd"));
This will print the storage required for str1, which is a pointer to
char and pointer size is 4. This is irrespective of the length of the
string it's assigned to.
str2 and "abcd" required '\0' at the end of their string. So, they
require 4 + 1 = 5 bytes of storage and print 5. In this case,
sizeof(constant string) = strlen(constant string) + 1;

Regards,
Raju

ra*******@gmail.com wrote: hello,
what is difference between sizeof("abcd") and strlen("abcd")? why
both functions gives different output when applied to same string
"abcd".
I tried following example for that.
#include <stdio.h>
#include <string.h>
void main()
{
char *str1="abcd";
char str2[]="abcd";
printf("%d %d %d",sizeof(str1),sizeof(str2),sizeof("abcd"));
printf("%d %d %d",strlen(str1),strlen(str2),strlen("abcd"));
}


Nov 15 '05 #7

P: n/a

RAJU wrote:
Hi Rahul,

First of all, sizeof() and strlen() are differnt. The sizeof() is an
operator which gives the number of bytes required to store an object of
the type of it's operand and the strlen() is a function which takes a
constant string as an input and returns length of it's argument string.

If a constant string "abcd" is passed then strlen() will always return
4.
printf("%d %d %d",sizeof(str1),sizeof(str2),sizeof("abcd"));

This will print the storage required for str1, which is a pointer to
char and pointer size is 4. This is irrespective of the length of the
string it's assigned to.


Wrong. Pointer variable size is not always 4. Its implementation
specific.

Nov 15 '05 #8

P: n/a

Suman wrote:
ra*******@gmail.com wrote:
hello,
what is difference between sizeof("abcd") and strlen("abcd")? why
1. Sizeof is an unary operator. Strlen is a function defined in
string.h.

2. Strlen looks for the first null('\0') and when found returns the
number
of characters that precede the null character.
both functions gives different output when applied to same string


See above.
"abcd".
I tried following example for that.
#include <stdio.h>
#include <string.h>
void main()

should be
int main()
{
char *str1="abcd";
char str2[]="abcd";

Among other things, strlen() returns a size_t object, and you should
use
the `z' length modifier, followed by a conversion specifier d,i,o,u, x
or X.

Sizeof again yields the size of an object and using the specifier for
size_t
(and a cast, I'm not sure if required, before printing) should again be
preferred.
> printf("%d %d %d",sizeof(str1),sizeof(str2),sizeof("abcd"));
printf("%d %d %d",strlen(str1),strlen(str2),strlen("abcd"));
}


Do something like

#define DIM(x) sizeof x / sizeof x[0] char str[12];
strcpy(str, "hello");
printf("%zu vs %zu\n", DIM(str), strlen(str));
and you'll know.


Nov 15 '05 #9

P: n/a
You are right. Pointer variable is not always 4. But, on most of the
current 32-bit systems it's 4 bytes.It can be 8 bytes also. Every thing
is depends on Memory Management.

I just wanted to make a point that it's of fixed size for an
environment and it doesn't depend on the input string,

Thanks,
Raju

Nov 15 '05 #10

P: n/a
On Fri, 05 Aug 2005 02:25:57 -0700, Antonio Contreras wrote:

....
> I tried following example for that.
> #include <stdio.h>
> #include <string.h>
> void main() ^^^^


....
Indeed it is possible. Most compilers won't issue a warning if you set
the return type to void. They will silently insert code to return a 0
and just go on.


Or more likely they won't, the'll just generate code for a function that
returns void. Depending on how the implementation works that may or may
not work where a function that returns int is required. Sometimes it works
and you'll get a garbage value back, but it may not work at all, there's
no guarantee that a main returning void will even be called successfully.

Lawrence

Nov 15 '05 #11

P: n/a
In article <11*********************@f14g2000cwb.googlegroups. com>,
<ra*******@gmail.com> wrote:
hello,
what is difference between sizeof("abcd") and strlen("abcd")? why
both functions gives different output when applied to same string
"abcd".
I tried following example for that.
#include <stdio.h>
#include <string.h>
void main()
{
char *str1="abcd";
char str2[]="abcd";
printf("%d %d %d",sizeof(str1),sizeof(str2),sizeof("abcd"));
printf("%d %d %d",strlen(str1),strlen(str2),strlen("abcd"));
}


You'd think the trolls would at least be a little creative.

Personally, I prefer to declare it as "double *main()".
Works just as well.

Nov 15 '05 #12

P: n/a

Kenny McCormack wrote:
In article <11*********************@f14g2000cwb.googlegroups. com>,
<ra*******@gmail.com> wrote:
hello,
what is difference between sizeof("abcd") and strlen("abcd")? why
both functions gives different output when applied to same string
"abcd".
I tried following example for that.
#include <stdio.h>
#include <string.h>
void main()
{
char *str1="abcd";
char str2[]="abcd";
printf("%d %d %d",sizeof(str1),sizeof(str2),sizeof("abcd"));
printf("%d %d %d",strlen(str1),strlen(str2),strlen("abcd"));
}


You'd think the trolls would at least be a little creative.

Personally, I prefer to declare it as "double *main()".
Works just as well.


THANKS everybody i understood difference between sizeof operator and
strlen function.

Nov 15 '05 #13

P: n/a
"RAJU" <ka****@cadence.com> writes:
You are right. Pointer variable is not always 4. But, on most of the
current 32-bit systems it's 4 bytes.It can be 8 bytes also. Every thing
is depends on Memory Management.

I just wanted to make a point that it's of fixed size for an
environment and it doesn't depend on the input string,


Correct, but "pointer size is 4" was perhaps not the best way to make
that point.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #14

P: n/a
Suman wrote on 05/08/05 :
1. Sizeof is an unary operator. Strlen is a function /defined/ in
string.h.


erm... declared...

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"It's specified. But anyone who writes code like that should be
transmogrified into earthworms and fed to ducks." -- Chris Dollin CLC
Nov 15 '05 #15

P: n/a
RAJU wrote on 05/08/05 :
First of all, sizeof() and strlen() are differnt. The sizeof() is an


The is no sizeof() operator. It's sizeof. The () are around the types
(like a typecast)

int a;

size_t n = sizeof a;

n = sizeof (int);

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"Mal nommer les choses c'est ajouter du malheur au
monde." -- Albert Camus.
Nov 15 '05 #16

P: n/a
(supersedes <mn***********************@YOURBRAnoos.fr>)

RAJU wrote on 05/08/05 :
First of all, sizeof() and strlen() are differnt. The sizeof() is an


There is no sizeof() operator. It's sizeof. The () are around the types
(like a typecast)

int a;

size_t n = sizeof a;

n = sizeof (int);
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"It's specified. But anyone who writes code like that should be
transmogrified into earthworms and fed to ducks." -- Chris Dollin CLC
Nov 15 '05 #17

P: n/a
ra*******@gmail.com wrote on 05/08/05 :
void main()
<...>
THANKS everybody i understood difference between sizeof operator and
strlen function.


.... but you still don't understand the declaration of main()...

The following are conforming to the C-language standard definition:

int main ();
int main (void);
int main (int, char **);

others are not standard and invokes an undefined behaviour.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"Mal nommer les choses c'est ajouter du malheur au
monde." -- Albert Camus.
Nov 15 '05 #18

P: n/a
(supersedes <mn***********************@YOURBRAnoos.fr>)

ra*******@gmail.com wrote on 05/08/05 :
void main()
<...>
THANKS everybody i understood difference between sizeof operator and
strlen function.


.... but you still don't understand the declaration of main()...

The following are conforming to the C-language standard definition:

int main ();
int main (void);
int main (int, char **);

others are not standard and invoke an undefined behaviour.
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"
Nov 15 '05 #19

P: n/a
In article <mn***********************@YOURBRAnoos.fr>,
Emmanuel Delahaye <em***@YOURBRAnoos.fr> wrote:
(supersedes <mn***********************@YOURBRAnoos.fr>)

ra*******@gmail.com wrote on 05/08/05 :
void main()

<...>
THANKS everybody i understood difference between sizeof operator and
strlen function.


... but you still don't understand the declaration of main()...

The following are conforming to the C-language standard definition:

int main ();
int main (void);
int main (int, char **);

others are not standard and invoke an undefined behaviour.


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

(Yes, I know the distinction may be moot in the context of this NG - the
equivalent of discussing the difference between a class 2 mortal sin and
a class 3 mortal sin in other religious contexts)

Anyway, I still think declaring it as: double *main(double,struct stat)
would be better for the newbies.

Nov 15 '05 #20

P: n/a
Kenny McCormack wrote:

In article <mn***********************@YOURBRAnoos.fr>,
Emmanuel Delahaye <em***@YOURBRAnoos.fr> wrote:
(supersedes <mn***********************@YOURBRAnoos.fr>)

ra*******@gmail.com wrote on 05/08/05 :
> void main()

<...>
THANKS everybody i understood
difference between sizeof operator and
strlen function.


... but you still don't understand the declaration of main()...

The following are conforming to the C-language standard definition:

int main ();
int main (void);
int main (int, char **);

others are not standard and invoke an undefined behaviour.


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.

--
pete
Nov 15 '05 #21

P: n/a
ga*****@yin.interaccess.com (Kenny McCormack) writes:
In article <mn***********************@YOURBRAnoos.fr>,
Emmanuel Delahaye <em***@YOURBRAnoos.fr> wrote:

[...]
The following are conforming to the C-language standard definition:

int main ();
int main (void);
int main (int, char **);

others are not standard and invoke an undefined behaviour.


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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #22

P: n/a

Nov 15 '05 #23

P: n/a
Martin Ambuhl wrote:
void main()

^^^^
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)?
--
Anton Petrusevich
Nov 15 '05 #24

P: n/a
Anton Petrusevich <ca***@att-ltd.biz> wrote:
Martin Ambuhl wrote:
void main()

^^^^
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)?


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

Richard
Nov 15 '05 #25

P: n/a
Anton Petrusevich wrote:
Martin Ambuhl wrote:

void main()


^^^^
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)?


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.
Nov 15 '05 #26

P: n/a
Anton Petrusevich wrote:
Martin Ambuhl wrote:
void main()


^^^^
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)?


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?
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
Nov 15 '05 #27

P: n/a
Richard Bos 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)?

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.
--
Anton Petrusevich
Nov 15 '05 #28

P: n/a
On Mon, 08 Aug 2005 08:36:15 +0200, Anton Petrusevich wrote:
Martin Ambuhl wrote:
void main()

^^^^
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)?


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

Nov 15 '05 #29

P: n/a
Anton Petrusevich <ca***@att-ltd.biz> writes:
Richard Bos 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)?

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.


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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #30

P: n/a
Lawrence Kirby wrote:
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
Nov 15 '05 #31

P: n/a
Keith Thompson wrote:
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.
--
Anton Petrusevich
Nov 15 '05 #32

P: n/a
In article <dd*************@news.t-online.com>,
Anton Petrusevich <ca***@att-ltd.biz> wrote:
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
Nov 15 '05 #33

P: n/a
Richard Tobin wrote:
"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?
--
Anton Petrusevich
Nov 15 '05 #34

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


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.

--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)
Nov 15 '05 #35

P: n/a
In article <dd*************@news.t-online.com>,
Anton Petrusevich <ca***@att-ltd.biz> wrote:
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
Nov 15 '05 #36

P: n/a
Stephane Zuckerman wrote:
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 :)
--
Anton Petrusevich
Nov 15 '05 #37

P: n/a
On 2005-08-08, Anton Petrusevich wrote:
Keith Thompson wrote:
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.


int main(void) is guaranteed to work.

void main() is not guaranteed to work.

What's religious about that?

--
Chris F.A. Johnson <http://cfaj.freeshell.org>
================================================== ================
Shell Scripting Recipes: A Problem-Solution Approach, 2005, Apress
<http://www.torfree.net/~chris/books/cfaj/ssr.html>
Nov 15 '05 #38

P: n/a
Anton Petrusevich <ca***@att-ltd.biz> writes:
Keith Thompson wrote:
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.


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


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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #39

P: n/a
Anton Petrusevich wrote:
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.
Nov 15 '05 #40

P: n/a
Anton Petrusevich wrote:
"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.
Nov 15 '05 #41

P: n/a
Anton Petrusevich <ca***@att-ltd.biz> writes:
Lawrence Kirby wrote:
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?


void main() is actually an unusual case, and perhaps not the best one
for illustrating the concept of undefined behavior.

The standard explicitly allows an implementation to define the
behavior of alternative definitions of main(), including void
main(void), but it does not require any implementation to do so. For
an implementation whose documentation *doesn't* mention void main(void),
the behavior of
void main(void){}
is undefined (see also "nasal demons"). For an implementation that
*does* explicitly document it, the behavior is implementation-defined.

In a sense, the extra permission given by the standard is redundant,
since an implementation is free to document anything it likes,
including defining the behavior of constructs that, as far as the
standard is concerned, invoke undefined behavior.

In a way, it's similar to what happens on integer overflow. The
following code fragment:

int i = 32767;
i ++;

invokes undefined behavior under an implementation with
INT_MAX == 32767, but is well defined where INT_MAX > 32767.

Bottom line: always use one of the standard definitions of main()
unless you have a very good reason not to. Saving a few keystrokes is
not a very good reason. Using a freestanding implementation (most
likely an embedded system) may be a very good reason.

In response to comments made elsewhere in this thread, none of this
has anything whatsoever to do with "religion". We are simply giving
you the best advice we can. If this comes across as "You must do
things this way because you'll go to Hell if you don't!", please feel
free to ask for clarification. There's almost always a valid reason
for the advice we give, but we don't always necessarily make that
sufficiently clear.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #42

P: n/a
Anton Petrusevich wrote:

Richard Tobin wrote:
"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?


If the standard says that the implementation needs to define something
(for example, the size of an int), then it's "implementation defined".
If the standard places no constraints whatsoever (such as "i = i++")
then it's "undefined behavior".

Yes, a particular implementation may define what the "undefined behavior"
is on that aprticular implementation, but it's still undefined as far as
the standard goes.

Yes, the odds are that a given implementation's actions and a piece of
code that invokes undefined behavior will probably be consistent, even
if the implementors don't define it. But nothing requires it to be,
and it may change in the next release, even if it's a minor update,
like an update from 5.1.234.98 to 5.1.234.99 release. (Even an
implementation defined behavior can change, but it's not likely to
change in anything but a major version upgrad.)

For example:

#include <stdio.h>

int main(int argc,char *argv[])
{
float a, b, c;

c = a / b;

printf("%ld\n",c);

exit(EXIT_SUCCESS);
}

It may be that the particular implementation ensures that you will
get some sort of "divide by zero" abort. On the other hand, many
platforms are likely to give you "random" results, depending on
what happens to be in the memory used for the "a" and "b" floats.
Even if the platform has well-defined behavior for divide-by-zero,
floating point over/underflow, and so on, the only "definition" to
the behavior would begin "if the memory happens to contain..."

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
Nov 15 '05 #43

P: n/a
In article <dd***********@pc-news.cogsci.ed.ac.uk>,
Richard Tobin <ri*****@cogsci.ed.ac.uk> wrote:
In article <dd*************@news.t-online.com>,
Anton Petrusevich <ca***@att-ltd.biz> wrote:
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


Probably not relevant to *you* (Richard), but certainly relevant to Anton.

I'd wager, in fact, that whether or not Richard thinks something is
"undefined behaviour" is about as relevant to Anton as is whether or not
Anton thinks something is "undefined behaviour" is to Richard.

Nov 15 '05 #44

P: n/a
In article <gs**************@newsread1.news.atl.earthlink.net >,
Martin Ambuhl <ma*****@earthlink.net> wrote:
Anton Petrusevich wrote:
"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.


Define "pseudo-anarchism" in this context. In the sense that you are using
it, how is it different from (real) anarchism? Why the distinction?

Nov 15 '05 #45

P: n/a
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:
....
In response to comments made elsewhere in this thread, none of this
has anything whatsoever to do with "religion". We are simply giving
you the best advice we can. If this comes across as "You must do
things this way because you'll go to Hell if you don't!", please feel
free to ask for clarification. There's almost always a valid reason
for the advice we give, but we don't always necessarily make that
sufficiently clear.


I'm going to say this briefly and hope that the more intelligent readers
can fill in the blanks and not worry about the lack of all the lawyerly
bells and whistles that are ordinarily necessary.

The content of this ng is religious in the sense that it has to do with the
contents of a document - and, by extension, the goings on of the minds of
the individuals who wrote that document. Science, on the other hand, is
concerned with physical phenomena - things that are, in theory at least,
verifyable by physical experimentation. So, in terms of science, someone
can say "I've tested it - I've convinced myself - void main() works just
fine" (*). Then religion comes along and says "No, it doesn't work - you
cannot trust your senses. The document [sacred text] says it does not
work". This is the essence of religion.

I think the point is not so much that any particular thing (such as that
which is currently under discussion) is a matter of religion as that the
entire scope and charter of this ng is much more in line with a religious
framework than that of a scientific one.

And that's a strange thing to find in an ng under the comp.* hierarchy.

(*) Equivalently: "They do move".

Nov 15 '05 #46

P: n/a
>The content of this ng is religious in the sense that it has to do with the
contents of a document - and, by extension, the goings on of the minds of
the individuals who wrote that document. Science, on the other hand, is
concerned with physical phenomena - things that are, in theory at least,
verifyable by physical experimentation. So, in terms of science, someone
can say "I've tested it - I've convinced myself - void main() works just
fine" (*). Then religion comes along and says "No, it doesn't work - you
cannot trust your senses. The document [sacred text] says it does not
work". This is the essence of religion.


Problems with void main() are observable. When I use such a program
in a Makefile, it usually blows off the make with an error, because
it returns status that looks like an error to make.

Gordon L. Burditt
Nov 15 '05 #47

P: n/a
On Mon, 08 Aug 2005 19:16:46 GMT, ga*****@yin.interaccess.com (Kenny
McCormack) wrote:
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:
...
In response to comments made elsewhere in this thread, none of this
has anything whatsoever to do with "religion". We are simply giving
you the best advice we can. If this comes across as "You must do
things this way because you'll go to Hell if you don't!", please feel
free to ask for clarification. There's almost always a valid reason
for the advice we give, but we don't always necessarily make that
sufficiently clear.
I'm going to say this briefly and hope that the more intelligent readers
can fill in the blanks and not worry about the lack of all the lawyerly
bells and whistles that are ordinarily necessary.

The content of this ng is religious in the sense that it has to do with the
contents of a document - and, by extension, the goings on of the minds of
the individuals who wrote that document. Science, on the other hand, is
concerned with physical phenomena - things that are, in theory at least,
verifyable by physical experimentation. So, in terms of science, someone
can say "I've tested it - I've convinced myself - void main() works just
fine" (*).


No scientist would accept this as proof that void main() works just
fine in another environment, or even at another time. It says only
that this particular use, in this particular program, on this
particular implementation, with the particular inputs used, worked as
many times as I tested it. Any extension of this religious belief must
be based on faith.
Then religion comes along and says "No, it doesn't work - you
cannot trust your senses. The document [sacred text] says it does not
work". This is the essence of religion.
But nobody here is saying that. What we are saying is that the
standard does not define what it does. That's an observable fact, as
scientific as it gets. Proof requires only that one read the standard.
I think the point is not so much that any particular thing (such as that
which is currently under discussion) is a matter of religion as that the
entire scope and charter of this ng is much more in line with a religious
framework than that of a scientific one.

And that's a strange thing to find in an ng under the comp.* hierarchy.

(*) Equivalently: "They do move".

--
Al Balmer
Balmer Consulting
re************************@att.net
Nov 15 '05 #48

P: n/a
Keith Thompson wrote:
and since the latter is portable, there is no advantage in using the
former.
Good point. This is just my experience that says me: "I have never seen a C
compiler which generated different symbols for void main() and for int
main()". And so in my mind it's not a big deal which defenition to use.
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.
If you would call ANSI/ISO C standard as "Bible"... :)
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.)


Is my English so bad?
--
Anton Petrusevich
Nov 15 '05 #49

P: n/a
On Mon, 08 Aug 2005 22:12:28 +0200, in comp.lang.c , Anton Petrusevich
<ca***@att-ltd.biz> wrote:
This is just my experience that says me: "I have never seen a C
compiler which generated different symbols for void main() and for int
main()".
I have, and so have many others in this group. On at least one machine
I've used, void main() would cause the app to crash on exit, and/or
generate random error messages on the console.
If you would call ANSI/ISO C standard as "Bible"... :)
In this group, the ISO standard /is/ the Bible.
Is my English so bad?


its okay, I've read much worse.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Nov 15 '05 #50

83 Replies

This discussion thread is closed

Replies have been disabled for this discussion.