Misdeclaring "main" (was: Re: system 5 vrs. bsd4.3 question)

[Garrett A. Wollman]

In article <2268 at auspex.auspex.com>, guy at auspex.auspex.com (Guy Harris) writes:
> 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"...  This presumably changed the calling sequence of
> "main" in such a way as to scramble the incoming arguments.
> [. . .]

It is, of course, obvious, that if we used ANS C-compatible function
prototypes, this sort of problem would never get past the compiling
stage.  For instance, if you had:


int main(int,char **);

struct foo {
	int i,j;
	double k;
}

main( /* and so on */


The cmompiler would pick up the mismatch.  Of course, if you're using
prototypes, then your compiler also supports ~voids~ and stuff like
that, so you (if you were a careful coder) wouldn't even fall back on
this, but get a syntax error right away.

I use the type-mismatch trick to help me bring archaic forms up to ANS. 
I can look through the file and create prototypes for each function,
which I put at the beginning of the file.  Then, I let the compiler
bring me to all the type mismatches, which will be the points where a
void function was not declared as void.  Saves a lot of time.

Actually, the whole business of prototyping saves me a considerable
amount of debugging time.  This allows me to catch errors such as
passing a char to a function which takes an int, when the char was
supposed to be unsigned.  (Don't think this is a problem?  Try writing
to a file, using fputc('\xff',fp).  The '\xff' will be sign-extended to
-1.)

-GAWollman

-- 
"(-::-)"    (Siamese twins)   | "This is a public-access system, so I don't 
gwollman at tnl.UUCP             |  know what the operator's opinions are."
             ...uunet!uvm-gen!tnl!gwollman