Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!gatech!bloom-beacon!husc6!purdue!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.sources.d
Subject: Re: Mea Culpa Re: Something's Broken: was ... Re: tgetent
Keywords: tgetent,core dump,sco,xenix,large model
Message-ID: <12656@mimsy.UUCP>
Date: 23 Jul 88 15:02:47 GMT
References: <54@libove.UUCP> <701@nod2sco> <3222@bigtex.uucp> <1033@ficc.UUCP> <19964@watmath.waterloo.edu>
Distribution: comp
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 50

In article <19964@watmath.waterloo.edu> rwwetmore@grand.waterloo.edu (Ross
Wetmore) writes:
>>:  The fact that NULL, defined as the integer constant 0, is explicitly
>>:defined to be a valid null pointer on assignment (but not generally, 
>>:which is what caused the original problem) only reinforces the linkage.
[between pointers and integers]

It may have been a design mistake, but it is not a fatal one.

[someone else, name forgotten:]
>>No, (char *) NULL is the null pointer.

There is no `the null pointer': there are an infinite variety of nil
pointers.  (char *)NULL is `the nil pointer to char', and nothing else.
There are many machines on which `char *' pointers have more bits, or
have bits in different places, than other pointers; there is at least
one machine on which pointers to functions are nine times longer than
pointers to data.  From this it is easy to see why the proper cast is
required: any other cast may give you the wrong number of bits, or the
right number of bits but in the wrong order.

>  K&R also says that the result of pointer arithmetic is an int.

Rather, that the result of pointer *subtraction* is an int.  In the
draft proposed American National Standards C Standard X3J11, the
result is defined as an object of type `ptrdiff_t', which is simply
a signed integral type (and hence may be `long' rather than `int').
This, along with `size_t', removes the existing restriction that any
single object may not be larger than an int-worth.

>  While pointers and ints are declared to be of different sizes, somehow 
>the size of an int and a pointer are still linked by such constructs.
>This means that pointer code which runs fine on a 32-32 machine fails 
>inexplicably on a 32-16 machine where the only diifference in the
>machines is changing the size of an int from 32 to 16. 

Only if (assuming a byte-addressed machine) objects on the 32-16 machine
are allowed to span more than 65536 bytes, and only under K&R rules, not
under the dpANS rules.  Note that so-called `huge model' compilers for
the IBM PC use rules closer to those in the dpANS (so that they will be
useful).

>I still think C works best on machines where pointers and ints
>are the same size :-)

Certainly lazily-written C code works best on machines where this is
true (and where pointers are untagged and everything is byte-addressed).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris