ekrell@ulysses.att.com (12/03/88)
The optimizer for the sparc is known to be broken, so avoid using it. I couldn't get X Windows 11.3 running until I removed the -O flag from the Makefiles. the "Watchdog Reset" problem with the 4/110 is a hardware bug for which Sun has a software workaround (a new trap.o kernel module). This will Prevent the system from crashing. > char argv[SOMEARGS][BUFSIZ]; > foo (argv); > foo (argv) > char **argv; > { > printf( "%s\n", argv[1]); > } You didn't expect this to work, did you? How does the function know what offset to generate for argv[1]? It has to know the second dimension of the matrix in order to generate right offsets. Try declaring the argument in foo() as "char argv[][BUFSIZ]".
henry@uunet.uu.net (12/04/88)
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 ]]
domae@nrtc.northrop.com (Terry Domae) (12/04/88)
I would like to thank everyone who came back with positive responses on
this subject. Apparently there were many responses that I got back from
people within sun, but the customer support department in SUN seems to be
overloaded. I got the following information from all the responses, and
might be of interest to the general list:
1) There is a new compiler available from sun in the release 4.0.1
which corrects ``many problems''. According to SUN customer support
this is available starting in the first few weeks of Dec88. This goes
for the Optimizer too which had some serious flaws accoring to SUN
customer support.
2) There is a kernel workaround to the hardware bugs in the 4/110 also
available in the 4.0.1 release. The module changed is trap.o, thus
user programs cannot crash the machine in spite of C programatic
errors.
3) The graph program suffers from a compiler bug, functions which
return floats do not convert their values to double (as it is suppose
to). There are patch tapes available from SUN for graph.
4) SUN support, nor any one else could summarize the problems with the
compiler.
Terry Domae <domae@nrtc.northorp.com>
Northrop Reaserch and Technology Center
One Research Park
Palos Verdes, Ca. 90274