Path: utzoo!utgpu!water!watmath!grand!rwwetmore
From: rwwetmore@grand.waterloo.edu (Ross Wetmore)
Newsgroups: comp.sources.d
Subject: Re: Something's Broken: was ... Re: tgetent
Keywords: tgetent,core dump,sco,xenix,large model
Message-ID: <19829@watmath.waterloo.edu>
Date: 12 Jul 88 16:26:59 GMT
References: <54@libove.UUCP> <701@nod2sco> <3222@bigtex.uucp> <1033@ficc.UUCP> <19789@watmath.waterloo.edu> <1305@ucsfcca.ucsf.edu>
Sender: daemon@watmath.waterloo.edu
Reply-To: rwwetmore@grand.waterloo.edu (Ross Wetmore)
Distribution: comp
Organization: U. of Waterloo, Ontario
Lines: 57

In article <1305@ucsfcca.ucsf.edu> root@cca.ucsf.edu (Computer Center) writes:
>In article <19789@watmath.waterloo.edu>, rwwetmore@grand.waterloo.edu (Ross Wetmore) writes:
>>   The assumption that pointers and ints are of equal length is the 
>> problem, no? This is a fundamental assumption of the 'C' language, 
>> if not an explicit requirement.
>Please learn what you are talking about before posting. See K&R p. 210
>    A pointer may be converted to any of the integral types large
>    enough to hold it. Whether an int or long is required is machine
>    dependent.
>Thos Sumner       (thos@cca.ucsf.edu)   BITNET:  thos@ucsfcca

  Since this obviously touches a sensitive nerve of the C purists, let
me rephrase with examples. As well, let us keep the discussion on a 
relatively Platonic plane, and avoid the religious fervor that leads
to argument by drowning the opposition with insult :-)

  (int)n = (char *)p - (char *)q;

  This is perfectly valid 'C' and will never to my knowledge be picked
up by any lint program. While 'C' goes to great lengths to tell you all
about the non-portability of many of its features (I have read the 
Bible above from cover to cover), the above statement has a fundamental
assumption that the separation of two addresses is representable by an
integer value, or if you regress one step taking into account the
warning that such expressions should only be used when p and q are
addresses within the same object, that the size of any C object cannot
exceed the number of items that can be held in an integer word.

  The related case has similar fundamental linkages between the size of
an integer word and pointers.

  (char *)p += n;

  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.

  C goes to great lengths to warn you about all the problems that arise 
when you make the assumption that an integer word and pointer are
interchangeable, or that pointer arithmetic must be done with integer
sized words. The bottom line is that C code must restrict itself to the 
subset of cases where the size of the address space can be represented
by an int and vice versa, or it develops a lot of non-portable extensions
(warts :-) such as the example of NULL which is valid for use in some
cases but not in others. 

  Thus the observation that pristine/portable C has a fundamental
assumption built into it about the relative sizes of pointers and ints.
Violating this assumption leads to non-portable extensions of the
language. The fact that C specifications go to great lengths not to
make this an explicit requirement, does not stop it from being a
practical fundamental assumption.

Ross W. Wetmore                 | rwwetmore@water.NetNorth
University of Waterloo          | rwwetmore@math.Uwaterloo.ca
Waterloo, Ontario N2L 3G1       | {uunet, ubc-vision, utcsri}
(519) 885-1211 ext 3491         |   !watmath!rwwetmore