home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / c / 18828 < prev    next >
Encoding:
Internet Message Format  |  1992-12-23  |  2.3 KB
  1. Xref: sparky comp.lang.c:18828 comp.unix.bsd:10587
  2. Path: sparky!uunet!cs.utexas.edu!sun-barr!olivea!charnel!sifon!thunder.mcrcim.mcgill.edu!mouse
  3. From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
  4. Newsgroups: comp.lang.c,comp.unix.bsd
  5. Subject: Re: Segmentation faults
  6. Message-ID: <1992Dec23.170337.11019@thunder.mcrcim.mcgill.edu>
  7. Date: 23 Dec 92 17:03:37 GMT
  8. References: <1gricmINNsl@ub.d.umn.edu> <1992Dec18.134225.20548@Logix.DE> <veit.724925472@du9ds3>
  9. Organization: McGill Research Centre for Intelligent Machines
  10. Lines: 40
  11.  
  12. In article <veit.724925472@du9ds3>, veit@du9ds3.fb9dv.uni-duisburg.de (Holger Veit) writes:
  13. > In <1992Dec18.134225.20548@Logix.DE> jpm@Logix.DE (Jan-Piet Mens) writes:
  14. >> In <1gricmINNsl@ub.d.umn.edu> cbusch@ub.d.umn.edu (Chris) writes:
  15. >>>    Why is the following code producing a segmentation fault???
  16. >> void writexy(x,y,s)
  17. >> int x, y;
  18. >> char *s;                /* OTHERWISE DEFAULTS TO int !!! */
  19.  
  20. Right you are.  This was the only thing I saw that was obviously
  21. blatantly wrong, so I would conjecture that it's what's at fault.
  22.  
  23. > This is a real problem where sizeof(int) != sizeof(char*), for
  24. > instance with Turbo C or Microsoft C or similar 16bit junk.  But if
  25. > you compile this with a 32bit K&R compiler, and
  26. > sizeof(int)==sizeof(char*) (=4), it won't see a difference, because
  27. > it will just take 32bit from the parameter stack and push it as a
  28. > 32bit argument to printf.
  29.  
  30. You're assuming arguments go on a stack, with ints and char *s passed
  31. the same way.  A compiler for a 68000-family machine may well pass x
  32. and y in d0 and d1 with s in a0.  Of course, when s is undeclared (and
  33. thus defaulting to int) it would go in d2.  Thus, when writexy fetches
  34. s, it will use d2 rather than a0, and get junk.  (Printf will also have
  35. problems, which I'm sure you can fill in from this sketch.  <varargs.h>
  36. would be a little more complicated under such a system, but by no means
  37. impossible.)
  38.  
  39. > The compiler cannot find out the real expected type (it cannot do
  40. > parsing of the format string in general!).
  41.  
  42. Actually, under ANSI, it can, when the format string's contents can be
  43. determined at compile time, as they can here.  Not that it helps,
  44. because it is compelled to treat s as int.  (It would be free to
  45. produce a warning, of course; compilers are always free to produce
  46. whatever warnings they please.)
  47.  
  48.                     der Mouse
  49.  
  50.                 mouse@larry.mcrcim.mcgill.edu
  51.