Path: utzoo!utgpu!watmath!clyde!att!rutgers!mailrus!cornell!uw-beaver!rice!sun-spots-request From: attcan!utzoo!henry@uunet.uu.net Newsgroups: comp.sys.sun Subject: Re: SUN4 / SUNOS4.0 / C Compiler Problems Message-ID: <8811230523.AA10339@uunet.UU.NET> Date: 4 Dec 88 02:23:57 GMT Sender: usenet@rice.edu Organization: Rice University, Houston, Texas Lines: 61 Approved: Sun-Spots@rice.edu Original-Date: Wed, 23 Nov 88 00:23:54 EST X-Sun-Spots-Digest: Volume 7, Issue 37, message 1 of 12 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@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 ]]