print "foo" without using ;

L

Lawrence Kirby

C89 requires a return; C99 doesn't. Almost everyone posting has a C89
compiler; almost no one posting here has a C99 compiler. Doesn't it
make sense to require the return? Consider that there was no good
reason for the C99 standardization committee to allow this one exception
to the rule that functions that return values do so explicitly. The
inexcusable reason is that too many bad programmers had been writing
code in violation of the standard for the last 10 years.

C89 doesn't require a return. If you fall off the end of main() you get an
undefined termination status but not an invalid program. If the
program doesn't fall off the end of main() there's no problem at all.

However an undefined termination status is undesirable in normal
circumstances so falling off the end of main() is considered a bad thing,
hence the initial point above.

Lawrence
 
K

Kenneth Brody

Martin said:
C89 requires a return; C99 doesn't. Almost everyone posting has a C89
compiler; almost no one posting here has a C99 compiler. Doesn't it
make sense to require the return? Consider that there was no good
reason for the C99 standardization committee to allow this one exception
to the rule that functions that return values do so explicitly. The
inexcusable reason is that too many bad programmers had been writing
code in violation of the standard for the last 10 years.

Hmm... Using MSVC (hardly a "standard", I know)...

int main()
{
foo();
}
int foo()
{
}

This complains that foo() doesn't have a return, but doesn't complain
about main() not having a return. (Even with warnings all the way up.)
So, they appear to allow C99's exception. However, looking at the
generated assembly, they still follow the older "return from main is
the value of the last statement". (Basically, in MSVC's case, it means
that EAX isn't assigned any specific value, and so main will return
whatever foo returned.)

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>
 
R

Randy Howard

Mark wrote
(in article said:
You assume that the people conducting the interviews
know better? I'd wager that many would view void main()
as being perfectly acceptable.

Since I was speaking about myself, I know that the interviewer
knows better. :)
The problem stems from the fact that many text books
teach people to program using void main(); in their
examples.

Most famously Schildt I suspect. Since for some reason authors
that commit this mistake to print are extremely reluctant to
correct it in subsequent printings or even errata (I know,
because I have tried on several occasions, and been blown off or
insulted for my troubles, despite all attempts at making the
case politely).
Unless one is lucky enough to stumble
across one of the better books (or a forum such as
comp.lang.c) which points out the (portability) issue
they'll never know that void main(); is inappropriate.

Unless they bother to actually check a standard document.

I do wish gcc would spit out a warning on void main() except for
the embedded variants.
 
K

Keith Thompson

Randy Howard said:
I do wish gcc would spit out a warning on void main() except for
the embedded variants.

It does. I just tried versions 2.8.1, 2.95.2, 3.0.4, 3.4.4, and
4.0.0; they all print

void-main.c:2: warning: return type of `main' is not `int'

for the following:

void main(void)
{
}

even without any special options.

Unless you're saying you *don't* want the warning for the embedded
variants?
 
F

Fao, Sean

Rajesh said:
I was informed tht $SUBJECT was asked in M$ interview. Real imp. is no.
of ways to achive it.
mine sol. was....

Maybe I'm wrong, but I think everybody here is taking this too far. I
believe the intent of the interview question applied only to the line
printing "foo", which would make a return statement at the end a
perfectly legal solution.

#include <stdio.h>

int main(void)
{
if (printf("foo\n"))
{
}

return 0;
}

Agreed, it's a stupid question. But knowing the answer does
--somewhat-- prove an open-minded solution to a problem that tests ones
knowledge of C.

I already posted this link in another reply; but, it should be noted
that Microsoft is one of the few implementors that *has* defined a void
return type for function main().

http://msdn.microsoft.com./library/...ang_program_startup.3a_.the_main_function.asp
 
F

Flash Gordon

O

Old Wolf

Maybe I'm wrong, but I think everybody here is taking this too
far. I believe the intent of the interview question applied only
to the line printing "foo", which would make a return statement at
the end a perfectly legal solution.

#include <stdio.h>

int main(void)
{
if (printf("foo\n"))
{
}

return 0;
}

Unlikely, eg:

#include <stdio.h>
int main()
{
/* here is the line that prints foo! */
puts("foo")

/* there it was */

; return 0;
}

Of course, as has been pointed out on this thread, main does not
need a return statement.
 
R

Richard Bos

Denis Kasak said:
Sometimes I wonder if they're deliberately trying to break things.

....and then you wake up and realise that they've been known to do so,
and deliberately, for decades?

Richard
 
D

Denis Kasak

Richard said:
....and then you wake up and realise that they've been known to do so,
and deliberately, for decades?

I guess I'm still living in my little fantasy world where Microsoft
doesn't do so much damage to everything.

-- Denis
 
M

Mark McIntyre

Sometimes I wonder if they're deliberately trying to break things.

...and then you wake up and realise that they've been known to do so,
and deliberately, for decades?[/QUOTE]

Actually, that entry in the MSDN has been updated in the last year or
so. For a very long time, it said that main must return an int, and
immediately followed it by an example showing main returning void. Go
figure...

I also find the bit about exit() remarkable.
 
T

Thad Smith

Mostly off-topic, but perhaps surprising is the fact that Microsoft
actually accepts void as a valid return type.

http://msdn.microsoft.com./library/...ang_program_startup.3a_.the_main_function.asp

Not surprising here. The main reason that an OS (or other calling
environment) wouldn't accept a void function, rather than an function
returning int is that the calling convention is incompatible. Since C
evolved from K&R, which didn't have void types, and therefore used
default int type functions. When ANSI C was being developed and a void
type added, implementors wisely did not make calling void functions
incompatible with calling an int function. Of course, such calling
compatibility isn't guaranteed, but happens most of the time. What
implementations are you familiar with in which the calling convention
for a void function and an int function are different? I am not aware
of any.

Thad
 
M

Michael Wojcik

Not surprising here. The main reason that an OS (or other calling
environment) wouldn't accept a void function, rather than an function
returning int is that the calling convention is incompatible.

It's not a matter for the OS, but one for the implementation. An
implementation which runs on top of an OS might disallow "void main"
as an alternative, non-standard form because of some issue with that
OS, but there are certainly other possibilities. For example, an
implementation might disallow it because its authors wish to enforce
explicitly returning a valid status.

I'm curious to know how you determined that "calling convention"
(which is not covered by the standard) is the "main reason" for
disallowing alternative forms of main.
When ANSI C was being developed and a void
type added, implementors wisely did not make calling void functions
incompatible with calling an int function.

In what sense? The standard certainly makes calling a function
incorrectly - ie, with an incorrect prototype in scope, or without
a prototype in scope if the function is not declared in a manner
compatible with a non-prototyped function - an error, which sounds
like "incompatible" to me.
Of course, such calling compatibility isn't guaranteed,

If the standard doesn't guarantee compatibility, then it makes it
incompatible. There is no middle. "Happens to work" is a possible
result of undefined behavior; it doesn't demonstrate anything about
either the intentions or requirements of the standard.
What
implementations are you familiar with in which the calling convention
for a void function and an int function are different?

EPM C for the AS/400, for one.
I am not aware of any.

Anecdotal evidence, as always, demonstrates nothing about the C
language.
 
J

Joe Wright

Thad said:
Not surprising here. The main reason that an OS (or other calling
environment) wouldn't accept a void function, rather than an function
returning int is that the calling convention is incompatible. Since C
evolved from K&R, which didn't have void types, and therefore used
default int type functions. When ANSI C was being developed and a void
type added, implementors wisely did not make calling void functions
incompatible with calling an int function. Of course, such calling
compatibility isn't guaranteed, but happens most of the time. What
implementations are you familiar with in which the calling convention
for a void function and an int function are different? I am not aware
of any.

Thad
Utter nonsense. How can you possibly offer such trash in the group where
you know the masters live.

1. There is no term 'calling environment' in common parlance.
2. The term 'calling convention' is commonly used but you obviously
don't know what it means (look it up).
3. As of C89 we are allowed to declare and define generic functions of
type void. Nothing to do with calling convention.

The function main() is NOT a generic. It is the real name of your C
program. It is called by the command shell and has a 'value' of type
int. Not void, int! This was decided among Ken Thompson and Dennis
Ritchie circa 1972, three years before Bill, 19 years old in 1975
started Microsoft.

K&R (1978), C89 and C99 all define main() with type int.
 
K

Keith Thompson

Joe Wright said:
Utter nonsense. How can you possibly offer such trash in the group
where you know the masters live.

Actually, I think he's basically correct.
1. There is no term 'calling environment' in common parlance.

The term occurs in the standard, though in a slightly different
context, and the meaning seems clear enough.
2. The term 'calling convention' is commonly used but you obviously
don't know what it means (look it up).
3. As of C89 we are allowed to declare and define generic functions of
type void. Nothing to do with calling convention.

The function main() is NOT a generic. It is the real name of your C
program. It is called by the command shell and has a 'value' of type
int. Not void, int! This was decided among Ken Thompson and Dennis
Ritchie circa 1972, three years before Bill, 19 years old in 1975
started Microsoft.

K&R (1978), C89 and C99 all define main() with type int.

The reasons for making void functions and int functions de facto
compatible aren't related to main(), since main() has always returned
int. It has to do with other functions.

For example, in pre-ANSI C, a function that was not intended to return
a value might be have been written as:

do_something()
{
...
}

The function implicitly returns int, but it doesn't execute a return
statement and the callers don't attempt to use the result.

In ANSI C, it might be written as:

void do_something(void)
{
...
}

In the transition to ANSI C, many implementers presumably used
compatible calling sequences for these two cases to avoid breaking
existing code, or to allow pre-ANSI code to call ANSI code and vice
versa, or to allow C code to call assembly code, etc.

The fact that such implementations might make void main() compatible
with int main() is just a side effect (an unfortunate one, IMHO).
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,169
Messages
2,570,919
Members
47,458
Latest member
Chris#

Latest Threads

Top