hello world programme

[arnuld]

i compiled the "hello world" programme from K&R2:

#include<stdio.h>

int main() {

printf("hello world\n");

}


now i compiled it using: /gcc hello.c/

eveything went fine and programme ran.

when i compiled using:

 

[Ben Pfaff]

hello.c:6: warning: control reaches end of non-void function

this time programme runs too but what does that "warning mean"?

The main function should return a value, but you didn't provide a
return statement.

 

[Walter Roberson]

i compiled the "hello world" programme from K&R2:

#include<stdio.h>
int main() {
printf("hello world\n");
}

when i compiled using:

--------------------------------------------------
[arnuld@arch programming]$ gcc -ansi -pedantic -Wall -Wextra hello.c
hello.c: In function 'main':
hello.c:6: warning: control reaches end of non-void function
[arnuld@arch programming]$

this time programme runs too but what does that "warning mean"?

You declared main() as returning an int, but you failed to use
return to return a value from main.

 

[arnuld]

--------------------------------------------------

[arnuld@arch programming]$ gcc -ansi -pedantic -Wall -Wextra hello.c
hello.c: In function 'main':
hello.c:6: warning: control reaches end of non-void function
[arnuld@arch programming]$
this time programme runs too but what does that "warning mean"?

You declared main() as returning an int, but you failed to use
return to return a value from main.

so ANSI C requires it.

If you lie to the compiler, it will get its revenge. -- Henry Spencer

Ha....Ha.... that's means my program

 

[Walter Roberson]

You declared main() as returning an int, but you failed to use
return to return a value from main.

so ANSI C requires it.

No, main is special. In C89, failure to return a value results in
undefined behaviour -- the operating system might pick up any random
return status, and the operating system might do strange things
with some of the odd statuses.

In C99, failure to return a value from main is the same as returning 0.
However, in C99, you cannot define functions with the empty parameter
list; you would need int main(void) I believe.

Notice that what you got was a warning, not an error: a warning
is a note from the compiler to the effect of "Usually when I see
this pattern of code, a mistake has been made or something has been
overlooked, but you are the boss so I've gone ahead and compiled it
anyhow. I don't promise that what I interpreted it as is the
same as what you were expecting it to do, so you should probably
check this bit of code over carefully!"

 

[Default User]

i compiled the "hello world" programme from K&R2:

#include<stdio.h>

int main() {

printf("hello world\n");

}


now i compiled it using: /gcc hello.c/

eveything went fine and programme ran.

when i compiled using:

--------------------------------------------------
[arnuld@arch programming]$ gcc -ansi -pedantic -Wall -Wextra hello.c
hello.c: In function 'main':
hello.c:6: warning: control reaches end of non-void function
[arnuld@arch programming]$

It's telling you that you didn't return a value from a function that is
expected to do so. In C89, I believe this was legal for any function to
hit the end brace, which was the equivalent of a return with no
expression. That was legal under that standard, although undefined
behavior to use the return value.

In C99, they tightened that up and it's not legal to do any of that for
most functions, however there is an explicit exception for main() so
that it is equivalent to returning 0.

At any rate, the implementation is allowed to issue any diagnostics it
likes. As not having the return there may be an indication that the
programmer forgot, it's useful. For C89 implementations, that
indeterminant return value to the host system could be a problem.

Easy and desirable fix, add in at the end:

return 0;




Brian

 

[Richard Heathfield]

Walter Roberson said:

However, in C99, you cannot define functions with the empty
parameter list;

Chapter and verse, please. I think you're getting mixed up with implicit
int being dropped.

 

[Keith Thompson]

--------------------------------------------------
[arnuld@arch programming]$ gcc -ansi -pedantic -Wall -Wextra hello.c
hello.c: In function 'main':
hello.c:6: warning: control reaches end of non-void function
You declared main() as returning an int, but you failed to use
return to return a value from main.

so ANSI C requires it.

No, main is special. In C89, failure to return a value results in
undefined behaviour -- the operating system might pick up any random
return status, and the operating system might do strange things
with some of the odd statuses.

No, it merely causes an unspecified status to be returned to the
calling environment.

[snip]

 

[Walter Roberson]

(e-mail address removed)-cnrc.gc.ca (Walter Roberson) writes:

No, it merely causes an unspecified status to be returned to the
calling environment.

I just croschecked C89, and the wording is that the status value
returned is "undefined". So we are into the nitty gritty of exactly
what "undefined behaviour" is.

If it had used the wording you used, that the value was "unspecified",
the implication would be that there was -some- value that would be
returned -- possibly not a constant value, but that it'll get
-something-.

But as the wording says "undefined", I would take that as license for
the compiler to do something like attempt to grab a value from where it
-expects- a return value would be, and if the grabbing happens
upon a trapping value, then a trap could happen.

Hypothesize an implementation in which the ABI was such that
parameters were returned by setting a register to a pointer
to a return area (useful for passing back large structs, for example.)
It could be, even, that the calling routine was responsible for
allocating space for the return parameters and passing in that
pointer to the called routine, and that the called routine was
expected to save and return that pointer. Then the C 'return'
statement could be translated [in this scheme] into retrieving that
saved pointer, saving the return value there, and returning the pointer.
But in this scheme, if there was no 'return' then the register
used to return the pointer might get left in a random state,
possibly holding a value that, if interpreted as an address, would
result in a page fault. It seems to me that the "undefined"
wording of C89 would allow the fault -- i.e., "undefined behaviour",
whereas if the value is merely "unspecified" then although garbage
might get returned, a fault at that point would not be valid.

 

[Peter Nilsson]

Walter Roberson said:



Chapter and verse, please. I think you're getting mixed up with
implicit int being dropped.

Or possibly 6.11.6p1...

The use of function declarators with empty parentheses (not
prototype-format parameter type declarators) is an obsolescent
feature.

This was deprecated in C90 and remains so in C99. Despite the
warnings, it's unlikely to ever be removed from C. What is slightly
more likely is that C will ultimately follow C++'s rule that an
empty parameter list will be a prototype for a function taking
no parameters. When I say slightly more likely, I still think the
removal is highly unlikely since there are quite a few C programs
that actually rely on the current behaviour, whether the construct
is deprecated or otherwise.

 

[Guest]

I just croschecked C89, and the wording is that the status value
returned is "undefined". So we are into the nitty gritty of exactly
what "undefined behaviour" is.

Is the return status undefined, or is the behaviour undefined? Only if
the latter are all bets off.

 

[Keith Thompson]

I just croschecked C89, and the wording is that the status value
returned is "undefined". So we are into the nitty gritty of exactly
what "undefined behaviour" is.

Yes, that's a bit tricky. The standard defines the phrase "undefined
behavior", but not the word "undefined". If this hadn't been
superseded by C99, I'd argue that the wording needs to be cleaned up.

If it had used the wording you used, that the value was "unspecified",
the implication would be that there was -some- value that would be
returned -- possibly not a constant value, but that it'll get
-something-.

But as the wording says "undefined", I would take that as license for
the compiler to do something like attempt to grab a value from where it
-expects- a return value would be, and if the grabbing happens
upon a trapping value, then a trap could happen.

There's no such thing as a "trapping value". A "trap representation",
by definition, does not represent a value at all. My interpretation
is that the "undefined value" returned by "int main(void){}" cannot be
a trap representation.

This means, I suppose, that a conforming C90 implementation that
returns the contents of some arbitrary location would have to take
care that that location doesn't contain a trap representation -- but
this restriction has no effect on the vast majority of implementations
on which type int has no trap representations.

[...]

 

[Default User]

Is the return status undefined, or is the behaviour undefined? Only if
the latter are all bets off.

I think the behavior of the host system is always undefined. The only
thing the standard discusses is the return value itself.




Brian

 

[Richard Heathfield]

Harald van D?k said:

Is the return status undefined, or is the behaviour undefined? Only if
the latter are all bets off.

The former, so all bets are back on. We did this discussion a few years
ago. (I seem to recall that I lost.)

 

[Richard Heathfield]

Peter Nilsson said:

[...] 6.11.6p1...

The use of function declarators with empty parentheses (not
prototype-format parameter type declarators) is an obsolescent
feature.

This was deprecated in C90 and remains so in C99. Despite the
warnings, it's unlikely to ever be removed from C.

I'm delighted to hear you say so, because if it did happen it would
effectively outlaw generic function pointers. Bad plan, ISO! No
biscuit!

 

[Daniel Rudy]

At about the time of 2/12/2007 8:40 AM, arnuld stated the following:

i compiled the "hello world" programme from K&R2:

#include<stdio.h>

int main() {

printf("hello world\n");

}


now i compiled it using: /gcc hello.c/

eveything went fine and programme ran.

when i compiled using:

--------------------------------------------------
[arnuld@arch programming]$ gcc -ansi -pedantic -Wall -Wextra hello.c
hello.c: In function 'main':
hello.c:6: warning: control reaches end of non-void function
[arnuld@arch programming]$

The warning is a diagnostic message from the compiler that indicates
that a function that was defined as returning a value isn't.

You need to be *VERY* careful with this. Some operating systems will do
strange things depending on what it gets back. One case in point was
returning some arbitrary negative value that caused the ELF loader to
die with a segmentation fault, which then forced the kernel into a panic
situation.

This demonstrated a bug in the underlying operating system, but it also
demonstrates that if you define a function as returning a value, then
return a value, even if it's 0 (or NULL in the case of a pointer).

--
Daniel Rudy

Email address has been base64 encoded to reduce spam
Decode email address using b64decode or uudecode -m

Why geeks like computers: look chat date touch grep make unzip
strip view finger mount fcsk more fcsk yes spray umount sleep

 

[Mark McIntyre]

Peter Nilsson said:

[...] 6.11.6p1...

The use of function declarators with empty parentheses (not
prototype-format parameter type declarators) is an obsolescent
feature.

This was deprecated in C90 and remains so in C99. Despite the
warnings, it's unlikely to ever be removed from C.

I'm delighted to hear you say so, because if it did happen it would
effectively outlaw generic function pointers.

Would it? Isn't there a difference between a function declarator and a
pointer to a function?
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Richard Heathfield]

Mark McIntyre said:

Peter Nilsson said:

[...] 6.11.6p1...

The use of function declarators with empty parentheses (not
prototype-format parameter type declarators) is an obsolescent
feature.

This was deprecated in C90 and remains so in C99. Despite the
warnings, it's unlikely to ever be removed from C.

I'm delighted to hear you say so, because if it did happen it would
effectively outlaw generic function pointers.

Would it? Isn't there a difference between a function declarator and a
pointer to a function?

Function pointers are created using function declarators. See 3.5.4.3 or
its C99 equivalent.

 

[David Thompson]

arnuld wrote:

It's telling you that you didn't return a value from a function that is
expected to do so. In C89, I believe this was legal for any function to
hit the end brace, which was the equivalent of a return with no
expression. That was legal under that standard, although undefined
behavior to use the return value.

.... in the C code; since the initial call of main is (somehow) from
the environment it instead gives undefined termination status. (This
is still a bad thing, it's just a different bad thing from UB.)

In C99, they tightened that up and it's not legal to do any of that for
most functions, however there is an explicit exception for main() so
that it is equivalent to returning 0.

It is still legal but undesirable to hit the end brace of a non-void
function, which returns indeterminate value and using it is UB. What
changed is that an actual return statement in a non-void function can
no longer omit the expression (of or convertible to the return type).

And as you say, as a special case, end brace of main returns 0.
Actually this is only required _for the initial call_, but recursive
calls to main are almost always a bad idea anyway.

<snip rest>

- formerly david.thompson1 || achar(64) || worldnet.att.net