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