*BSD News Article 9278


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