main return value stange question

[Sweety]

hello to all members,

i have strange question in C.
main()
{
printf("%d",main) ;
}

here o/p is same for all m/c in TC++ version 3.0 i.e 657.
I think this is not garbage.
what u think??
plz reply.

 

[E. Robert Tisdale]

hello to all members,

i have strange question in C.
main()
{
printf("%d",main) ;
}

here o/p is same for all m/c in TC++ version 3.0 i.e 657.
I think this is not garbage.
what u think??

I think you be a sweet little troll.

plz reply.

> cat Sweety.c

#include <stdio.h>

main() {
printf("%d", main);
}

> gcc -Wall -std=c99 -pedantic -o Sweety Sweety.c

Sweety.c:3: warning: return type defaults to `int'
Sweety.c: In function `main':
Sweety.c:4: warning: int format, pointer arg (arg 2)

 

[Mike Wahler]

hello to all members,

i have strange question in C.
main()
{
printf("%d",main) ;
}

here o/p is same for all m/c in TC++ version 3.0 i.e 657.
I think this is not garbage.
what u think??

The behavior of the above program is undefined.

-Mike

 

[Eric Sosman]

hello to all members,

i have strange question in C.
main()
{
printf("%d",main) ;
}

here o/p is same for all m/c in TC++ version 3.0 i.e 657.
I think this is not garbage.
what u think??

It's garbage. More specifically, the program invokes
undefined behavior, and anything at all might happen. On
the system you are using at the moment, "anything at all"
appears to be "print 657," but that is not guaranteed.

The program exhibits undefined behavior for two reasons,
and "peculiar behavior" for two more:

- It calls a variadic function without a prototype in
scope. Functions that take a variable number of
arguments -- like printf() -- must be properly
declared before use, or undefined behavior results.
The best way to declare printf() is to #include
<stdio.h>.

- It uses the "%d" conversion specifier with a value
that is not an `int'. `main' in the printf() call
is a pointer to the function named `main', and a
function pointer is not an `int'. When you tell
printf() to expect an argument of one type (`int')
and actually supply something different (function
pointer), undefined behavior results.

- It fails to end its final (only) line of output with
a newline character '\n'. On some implementations,
the output may not appear at all unless each line
ends with a newline.

- It "drops off the end" of the `int'-valued function
main() without returning an `int' value. If the
environment tries to use the value returned by main()
as an indication of the program's success or failure
(most environments do this), great confusion can
result if main() fails to return a value.

 

[Christopher Benson-Manica]

The behavior of the above program is undefined.

Of course - the challenge is to enumerate all the different ways it
can explode I'll give it a shot...

1) main() will work fine on a C89 implementation, but will be rejected
by a mythical C99 implementation. Yes?
2) There is no newline in the printf.
3) Implicitly casting main's function pointer (is that what it is in that
context?) to an int.
4) Nothing is returned, which is fine for C99 but not C89... right?
5) stdio.h wasn't included (in the post itself, at least)

Does the behavior improve if the program is changed to

#include <stdio.h>

int main()
{
printf( "%p\n", (void *)main );
return EXIT_SUCCESS;
}

?

 

[Mark A. Odell]

#include <stdio.h>

int main(void)
{
printf("%p\n", (void *) main);
return EXIT_SUCCESS;
}

 

[Martin Ambuhl]

hello to all members,

i have strange question in C.
main()
{
printf("%d",main) ;
}

here o/p is same for all m/c in TC++ version 3.0 i.e 657.
I think this is not garbage.
what u think??
plz reply.

(From the top) I think that
1) You forgot to #include <stdio.h>, thus not providing the prototype for
the variadic function printf(). This is extremely naughty.
2) Since the Turbo C implementation you are using claims to be a C89
compiler, omitting the return type for main() is OK, since in C89 it
defaults to int. When you get a C99 compiler doing this becomes naughty.
3) Failing to terminate the last line of output with an end-of-line
character ('\n') results in implementation-defined behavior. This is very
naughty.
4) When you get a C99 compiler, leaving off the return statement (or call
to exit()) will be acceptable, although it is probably a good idea to
return an int from a function that promises to do so. main() is such a
function. However, you are using a C89 compiler. The same standard that
allows you to get away with omitting the return type [see #2], makes
leaving off the return statement result in implementation-defined behavior.
You have been naughty yet another time.

 

[Kevin Goodsell]

Of course - the challenge is to enumerate all the different ways it
can explode I'll give it a shot...

1) main() will work fine on a C89 implementation, but will be rejected
by a mythical C99 implementation. Yes?
2) There is no newline in the printf.
3) Implicitly casting main's function pointer (is that what it is in that
context?) to an int.

I'm not sure what you mean here. I don't think any conversion is
happening, though. A function pointer is passed, but printf expects an
int. The type mismatch is the only problem here, as far as I can tell.

4) Nothing is returned, which is fine for C99 but not C89... right?
5) stdio.h wasn't included (in the post itself, at least)

Does the behavior improve if the program is changed to

#include <stdio.h>

int main()
{
printf( "%p\n", (void *)main );
return EXIT_SUCCESS;
}

void * cannot portably contain a function address, only an object address.

-Kevin

 

[Christopher Benson-Manica]

I'm not sure what you mean here. I don't think any conversion is
happening, though. A function pointer is passed, but printf expects an
int. The type mismatch is the only problem here, as far as I can tell.

I guess I was trying to talk about the type mismatch, and blew it ;(

void * cannot portably contain a function address, only an object address.

I see. Thanks.

 

[Peter Shaggy Haywood]

Groovy hepcat E. Robert Tisdale was jivin' on Tue, 23 Dec 2003
13:17:32 -0800 in comp.lang.c.
Troll Alert: main return value stange question's a cool scene! Dig it!

I think you be a sweet little troll.

Well, well! Look who's calling the kettle black.

--

Dig the even newer still, yet more improved, sig!

http://alphalink.com.au/~phaywood/
"Ain't I'm a dog?" - Ronny Self, Ain't I'm a Dog, written by G. Sherry & W. Walker.
I know it's not "technically correct" English; but since when was rock & roll "technically correct"?

 

[Peter Shaggy Haywood]

Groovy hepcat Christopher Benson-Manica was jivin' on Tue, 23 Dec 2003
22:02:38 +0000 (UTC) in comp.lang.c.
Re: main return value stange question's a cool scene! Dig it!

Of course - the challenge is to enumerate all the different ways it
can explode I'll give it a shot...

1) main() will work fine on a C89 implementation, but will be rejected
by a mythical C99 implementation. Yes?

If you mean the declaration of main() without specifying the return
value (relying on implicit int), then yes.

2) There is no newline in the printf.
3) Implicitly casting main's function pointer (is that what it is in that
context?) to an int.

Nope. That's not happening here. The function designator, main, is
converted to a pointer to function, and this is passed to printf().
This is then treated as if it were an int (but is never cast, either
implicitly or explicitly, to anithing). I think that's what you meant.
The behaviour is undefined.

4) Nothing is returned, which is fine for C99 but not C89... right?

Not exactly. Something is returned, but in C90 it is an
indeterminate value.

5) stdio.h wasn't included (in the post itself, at least)

Right; so there is no prototype for printf(). Calling a var args
function without a prototype causes undefined behaviour.

Does the behavior improve if the program is changed to

#include <stdio.h>

int main()
{
printf( "%p\n", (void *)main );
return EXIT_SUCCESS;
}

Yes. Now we know it won't compile, since EXIT_SUCCESS is an
undeclared identifier. (Well, strictly speaking, in theory, we don't
know anithing except that a diagnostic will be produced. What happens
next is undefined. But in the real world, a compiler will cease
compilation.)

--

Dig the even newer still, yet more improved, sig!

http://alphalink.com.au/~phaywood/
"Ain't I'm a dog?" - Ronny Self, Ain't I'm a Dog, written by G. Sherry & W. Walker.
I know it's not "technically correct" English; but since when was rock & roll "technically correct"?

 

[Christopher Benson-Manica]

Yes. Now we know it won't compile, since EXIT_SUCCESS is an
undeclared identifier.

Hey, I accomplished something I seem to have a terminal problem
with neglecting to include <stdlib.h> when using EXIT_SUCCESS.