Path: utzoo!yunexus!geac!david
From: david@geac.UUCP (David Haynes)
Newsgroups: comp.sources.d
Subject: Re: Something's Broken: was ... Re: tgetent
Keywords: tgetent,core dump,sco,xenix,large model
Message-ID: <3027@geac.UUCP>
Date: 18 Jul 88 16:23:53 GMT
Article-I.D.: geac.3027
References: <54@libove.UUCP: <701@nod2sco: <3222@bigtex.uucp: <1033@ficc.UUCP: <19789@watmath.waterloo.edu: <1305@ucsfcca.ucsf.edu: <19829@watmath.waterloo.edu:
Reply-To: david@geac.UUCP (David Haynes)
Distribution: comp
Organization: Flame, Flame and Burn.
Lines: 101

In article <19829@watmath.waterloo.edu: rwwetmore@grand.waterloo.edu (Ross Wetmore) writes:
: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'

	Read about casting lvalues again.
:                              and will never to my knowledge be picked
:up by any lint program.

 	My compiler on the other hand barfs at this sort of thing.

:                        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.

Bullshit!

	Example:

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

	Therefore:

		All pointers are short.
		(True for PDP-11s)

Cast what you want, but don't make it a fundamental of the language.

:  The related case has similar fundamental linkages between the size of
:an integer word and pointers.
:
:  (char *)p += n;

So, let's expand this shall we? 

	(char *p) += n;
	==> (char *p) = (char *p) + n;
	==> (char *p) = (char *p) + (char *)n; 
	==> no violation. Remember, types are cast to the most complex
	    rvalue and then back to match the lvalue.


:  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.

No, (char *) NULL is the null pointer. 0 is 0. If you don't believe
that, I bet a lot of your 68000-based code crashes for no apparent 
reason.

:  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. 

So, if my ints are 32 bits and my pointers 64, I am not running K&R
C? Nonsense!

:  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.

Just because you can break the law, doesn't mean you are not doing
anything illegal. When talking about portable code, you had better
be planning to recognize the difference between a pointer and an
integer or you had better plan on spending late nights wondering
why your code keeps falling over. It's that simple --- K&R say a
pointer is a pointer and an integer is an integer and they may be of
different size. Live with it. 

:Ross W. Wetmore                 | rwwetmore@water.NetNorth

-david-