(* func)(fred, bert)

[Jon H. LaBadie]

In article <0200 at sheol.UUCP>, throopw at sheol.UUCP (Wayne Throop) writes:
> > darcy at bbm.UUCP (D'Arcy Cain)
> > I don't think it is "lying" to your compiler to 
> > [.. declare main an void ..].
> 
> I call declaring main an void "lying to your compiler" because in most
> environments you are perforce (or at least perprobably) going to be
> linking with a module that has declared it an int (eg: crt0 from many
> implementation of the C startup code).
> 
> > I should like to hear details of a case where the code will not
> > work.  It seems ridiculous to declare un-portable the results of a
> > void-vs-int return linkage which is never made, and I should like
> > to hear of an implementation where this actually fails.
> > If no real-world example is available, I should be almost as
> > satisfied with a conjectural example (clearly marked as conjecture).

I encountered one instance where "declaring" main to be other than int
caused severe problems.  The file containg main was organized as follows:

    #include <various.h>

    struct foo {
	various members;
    }

    /* 70 lines of comments - yes comments */

    main()
    {
	...
    }

Note the missing semicolon, failing to terminate the declaration of
struct foo, and thus serving to define main as a function returning a
struct foo.  The page+ of intervening comments were merely white space.

The development environment, a MC68010 UniSoft implementation, had no
problems.  One of the target environments, either a VAX 780, or a
Sritek co-processor for a PC/AT - I forget which, did have problems.
It core dumped upon exiting.

Imagine trying to explain to a client, the program you delivered runs
fine, does everything it is supposed to, it just core dumps every time
you use it.

Perhaps this is a more severe situation than a void vs. int lie about
main's return value.  But the principle remains intact - if the calling
and the called function are not in sync regarding their interface, then
the potential for trouble exists.

-- 
Jon LaBadie
{att, princeton, bcr}!jonlab!jon
{att, attmail, bcr}!auxnj!jon