Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP id AA5512 ; Fri, 01 Jan 93 01:47:43 EST Xref: sserve comp.lang.c:37186 comp.unix.bsd:9335 Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!olivea!charnel!sifon!thunder.mcrcim.mcgill.edu!mouse From: mouse@thunder.mcrcim.mcgill.edu (der Mouse) Newsgroups: comp.lang.c,comp.unix.bsd Subject: Re: Segmentation faults Message-ID: <1992Dec23.170337.11019@thunder.mcrcim.mcgill.edu> Date: 23 Dec 92 17:03:37 GMT References: <1gricmINNsl@ub.d.umn.edu> <1992Dec18.134225.20548@Logix.DE> <veit.724925472@du9ds3> Organization: McGill Research Centre for Intelligent Machines Lines: 40 In article <veit.724925472@du9ds3>, veit@du9ds3.fb9dv.uni-duisburg.de (Holger Veit) writes: > In <1992Dec18.134225.20548@Logix.DE> jpm@Logix.DE (Jan-Piet Mens) writes: >> In <1gricmINNsl@ub.d.umn.edu> cbusch@ub.d.umn.edu (Chris) writes: >>> Why is the following code producing a segmentation fault??? >> void writexy(x,y,s) >> int x, y; >> char *s; /* OTHERWISE DEFAULTS TO int !!! */ Right you are. This was the only thing I saw that was obviously blatantly wrong, so I would conjecture that it's what's at fault. > This is a real problem where sizeof(int) != sizeof(char*), for > instance with Turbo C or Microsoft C or similar 16bit junk. But if > you compile this with a 32bit K&R compiler, and > sizeof(int)==sizeof(char*) (=4), it won't see a difference, because > it will just take 32bit from the parameter stack and push it as a > 32bit argument to printf. You're assuming arguments go on a stack, with ints and char *s passed the same way. A compiler for a 68000-family machine may well pass x and y in d0 and d1 with s in a0. Of course, when s is undeclared (and thus defaulting to int) it would go in d2. Thus, when writexy fetches s, it will use d2 rather than a0, and get junk. (Printf will also have problems, which I'm sure you can fill in from this sketch. <varargs.h> would be a little more complicated under such a system, but by no means impossible.) > The compiler cannot find out the real expected type (it cannot do > parsing of the format string in general!). Actually, under ANSI, it can, when the format string's contents can be determined at compile time, as they can here. Not that it helps, because it is compelled to treat s as int. (It would be free to produce a warning, of course; compilers are always free to produce whatever warnings they please.) der Mouse mouse@larry.mcrcim.mcgill.edu