Xref: utzoo comp.unix.wizards:17356 comp.lang.c:20080
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.wizards,comp.lang.c
Subject: Misdeclaring "main" (was: Re: system 5 vrs. bsd4.3 question)
Message-ID: <2268@auspex.auspex.com>
Date: 21 Jul 89 18:58:27 GMT
References: <28398@beta.lanl.gov> <14020068@hpisod2.HP.COM>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Followup-To: comp.lang.c
Organization: Auspex Systems, Santa Clara
Lines: 47

>Sounds like SGI has an unusual argument passing method.

Nope.  It turned out the problem was that he'd written something like:

	struct foobar {
		...
	} <<<<<<<<<<<<<NOTE: missing semicolon!

	main(argc, argv)
		int argc;
		char *argv[];
	{
		...

The missing semicolon caused the "struct" declaration to get glued to
the definition of "main", so that "main" was being defined as returning
a "struct foobar".  This presumably changed the calling sequence of
"main" in such a way as to scramble the incoming arguments.

I've seen this error crop up before; it's certainly easy enough to make.
("For want of a semicolon, the program was lost....")

I like to explicitly declare the return type of *all* functions, even
those returning "int", and at least in ANSI C (and in most UNIX C
implementation) "main" does, in fact, return "int", so I declare it as
such.  I just realized that doing so can also catch this particular
mistake, since, while

	struct foobar {
		...
	}

	main(argc, argv)
	...

is legal (yes, really),

	struct foobar {
		...
	}

	int
	main(argc, argv)
	...

isn't.  So, always declare "main" as returning "int"; it may catch that
error someday....