SUN4 / SUNOS4.0 / C Compiler Problems

[attcan!utzoo!henry at uunet.uu.net]

Alas, although there probably are things wrong with the Sun4/4.0
compilers, a much bigger problem is that the SPARC is much less tolerant
of certain types of sloppy C programming than the 68020 was.

>	o VARARGS are not supported, except through a very strange
>	  macro package.

Varargs functions have **NEVER** been officially supported except through
that strange macro package.  Any software that assumes otherwise is
broken, and has always been broken.  Sometimes it worked on older
machines.

>	o The following program dealing with functions returning
>	  structures simply does not work...
>
>	struct test tester()
>	{
>	  printf ("Hi, the stack is all messed up now...\n");
>	  printf ("and you should get a core dump\n");
>	}

Try *returning a value* from the function that you have declared to return
a value.  This is again something that you could often be sloppy about on
older machines, but it has never been legitimate C.

>	  ... Note if the definition of the
>	  function foo's argument is changed from ``char **argv'' to
>	  ``char *argv[]'' things work ok. ...
>
>		char argv[SOMEARGS][BUFSIZ];
> ...
>		foo (argv);
> ...
>	foo (argv)
>	char **argv;

The problem here is that you are lying about the type you are passing to
foo.  Try declaring foo's argument as "char argv[SOMEARGS][BUFSIZ];".  The
first subscript will be ignored, actually, but the second one is important
and is *NOT* optional.  C has to know how big the elements of that array
are if it's to do proper subscripting into it.  Pointers and arrays are
*not* interchangeable everywhere in C, and this is one of the places where
the difference really matters.  I am surprised that this ever worked in
either form.  [[ Well, the code is flawed, but it shouldn't cause a
"watchdog reset"!  --wnl ]]

>	o Some basic strageness with respect to the optimizer.  Sometimes
>	  i've seen code compile and core dump, then recompiling without
>	  the -O flag causes it to work (with no code changes).

If the above are typical examples, then the code is basically wrong to
begin with, and it is not surprising that minor changes in how it is
compiled produce strange effects.

	Henry Spencer at U of Toronto Zoology
	uunet!attcan!utzoo!henry henry at zoo.toronto.edu

[[ Alas, I should have caught those when putting the message in a digest.
But I was too busy to look at it closely.  They are common mistakes.  My
thanks to the other posters who have sent in similar information.
--wnl ]]