return value of main

[Keith Thompson]

'int' is a type-specifier. 'void' is a type-specifier. 'void main' has
'void' used as a type-specifier instead of 'int' as a type-specifier. So,
the key issue is how was 'void' used as a type-specifier _before_ (i.e.,
from 1979-80) it was standardized as part of the C language. As I
indicated, 1) 'void', on compilers that didn't supply it, was defined to a
valid type-specifier, usually 'int' and 2) it was added to an important Unix
compiler of the era PCC. If programmers of the era understood that 'void'
was usually an alias for 'int', it wouldn't be an ignorant use, would it?
It would only be ignorant if they continued to use it long after C90.

Programmers of that era would have understood that "void", when used
as a return type, indicates that the function doesn't return a value,
but that the word could be aliased to "int" for compilers that didn't
yet directly support "void".

Declaring
void main()
is and was no more sensible than declaring
void n = 42;

The usual way to declare main back in the old days was simply:
main()
which was used in the examples in K&R1.

 

[Keith Thompson]

You could search for other slightly later references too. I just
posted the earliest I could find. See also reply to KT.

The point is that the references you posted *don't support your
claim*, which was specifically about "void main", not just "void".

If you want to dig up references that actually do support your claim,
feel free to do so.

You can post all the examples you like of people *using* "void main";
that doesn't demonstrate that those uses are based on anything other
than ignorance. If you can find any references that support your
claim that using "void main" was based on anything other than
ignorance, I'd be interested in seeing them.

 

[Dik T. Winter]

> 'int' is a type-specifier. 'void' is a type-specifier. 'void main' has
> 'void' used as a type-specifier instead of 'int' as a type-specifier.

Yes, and 'double main' has 'double' as a type-specifier instead of 'int'.
And 'struct {float re, im;} main' has again some other type-specifier.
What is the relevance?

> So,
> the key issue is how was 'void' used as a type-specifier _before_ (i.e.,
> from 1979-80) it was standardized as part of the C language.

Precisely as I wrote. To shut up lint complaining about unused function
returns.

> As I
> indicated, 1) 'void', on compilers that didn't supply it, was defined to a
> valid type-specifier, usually 'int'

Yes, because you wanted to compile.

> 2) it was added to an important Unix
> compiler of the era PCC.

Indeed, to be able to shut up lint.

> If programmers of the era understood that 'void'
> was usually an alias for 'int',

If they understood that, they did not understand it. 'void' as an alias
for 'int' would not shut up lint.

> it wouldn't be an ignorant use, would it?

It would be ignorance, not knowing the reason 'void' was added.

 

[Walter Banks]

In most freestanding embedded systems main is called but never exited. void main (void) makes sense. If main returns a value where is the result going to be sent?

In most automotive systems for example processors either never stop or run without exiting all of the time the vehicle is on. Most automotive processors have a single standalone application almost uniformly written in C.

w..

 

[Keith Thompson]

In most freestanding embedded systems main is called but never
exited. void main (void) makes sense. If main returns a value where
is the result going to be sent?

In most automotive systems for example processors either never stop
or run without exiting all of the time the vehicle is on. Most
automotive processors have a single standalone application almost
uniformly written in C.

Please provide context when posting a followup.

You're right, I've been ignoring freestanding implementations. (We
tend to do that here, probably more than we should.)

C99 5.1.2.1p1:

In a freestanding environment (in which C program execution may
take place without any benefit of an operating system), the name
and type of the function called at program startup are
implementation-defined.

So in that context,
void main(void)
is as legitimate as
int main(void)
which is as legitimate as
unsigned long _Startup(int foobar)
The implementation gets to decide how the startup function is to be
declared. And if the program never returns to the environment (or
there's no environment for it to return to), then "void main(void)" is
very likely to be the most sensible way to define it.

So let me amend my previous comments to refer only to hosted
environments.

 

[Chris Torek]

Read [the link] it is *not* about "void main"...

Indeed, it was about "void" itself. Of course if "void" were
simply "#define"d to "int", one could write:

#define void int
void main() { return 42; }

and the like; but this is equivalent to writing:

#define purple int
purple main() { return 42; }

Neither one is particularly sensible. If main() is to return an
"int" value, one might as well write "int main()" (or, in modern
C, "int main(void)"). (Of course one can add argc and argv as
usual.)

As an aside, "void" and PCC (Steve Johnson's Portable C Compiler)
long predate 4.1cBSD as well. The original BSD distributions were
on PDP-11s and related to V6 and V7 (Ken Thompson spent some time
at Berkeley, if I remember right) and at some point acquired the
PDP-11 version of PCC; the first VAX BSD distributions were derived
from 32V, which was sort of an offshoot of PWB Unix, and used PCC
from the beginning. Hence 3.0BSD, 4.0BSD, 4.1BSD, and both the
"a" and "b" versions of 4.1BSD (4.1a and 4.1b) used PCC along with
4.1c. The "a" through "c" versions were just various snapshots
along the way to the original 4.2BSD release, which was the first
"non-beta" release of sockets, fast file system, and so on.

(32V PCC had 8-character symbols as usual; I think it was somewhere
between 3.0 and 4.0BSD that Berkeley modified the compilers and
linkers to support longer names -- up to 1023 characters -- although
that may have been as late as 4.1BSD. This was probably mostly
for Berkeley Pascal, which strung nested function names together
with underscores. "Stabs" symbolic debugging was shoehorned in
shortly afterward, with Mark Linton's "dbx" debugger, which was
perhaps the first symbolic debugger for C code, although it was
originally part of the whole Pascal system.)