Path: utzoo!attcan!uunet!oddjob!ncar!ames!pasteur!ucbvax!decwrl!decvax!watmath!grand!rwwetmore
From: rwwetmore@grand.waterloo.edu (Ross Wetmore)
Newsgroups: comp.sources.d
Subject: Mea Culpa Re: Something's Broken: was ... Re: tgetent
Keywords: tgetent,core dump,sco,xenix,large model
Message-ID: <19964@watmath.waterloo.edu>
Date: 19 Jul 88 15:38:49 GMT
References: <54@libove.UUCP: <701@nod2sco: <3222@bigtex.uucp: <1033@ficc.UUCP: <19789@watmath.waterloo.edu: <1305@ucsfcca.ucsf.edu: <19829@watmath.waterloo.edu: <3027@geac.UUCP>
Sender: daemon@watmath.waterloo.edu
Reply-To: rwwetmore@grand.waterloo.edu (Ross Wetmore)
Distribution: comp
Organization: U. of Waterloo, Ontario
Lines: 69

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

  Right this was never intended to be a cast :-). While I might have
gotten away with 'int n = (char *)p - (char *)q;' what I really should
have done is made all the definitions explicitly, and avoided trying
to squish things down to a single line or at least been a little more
careful to double check what I had written as opposed to thought.
  My apologies for the confusion this may have caused.

  Moral: always use lint and spell on mail messages before posting :-)

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

  From the first line on pg 97 of K&R ...

#define NULL  0  /* pointer value for error report */

  QED. Your comment on 68K code crashing only reinforces my point.

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

  K&R also says that the result of pointer arithmetic is an int. And
any implementation of standard C functions I have ever seen has things
like strlen(), sizeof() ... returning an int-sized value. Note that
lseek() which refers to disk addresses returns a long (ie the largest
possible integer size on the machine).
  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. 

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

  No, I never said that. The correct conclusion was what my original
posting gave in counterpoint to the previous claim that an architecture
was broken if such code failed. The conclusion was that one could not
fault the architecture or compiler, and if anything was broken it was
the language specifications that permitted or dictated such 
inconsistencies. In fact the Intel architecture commented on enforces
strict conformance with K&R in the hardware.

  I like C just fine, and prefer it to many other languages I use, but
this still does not mean I have to be bashful about its shortcomings
either those explictly recorded in K&R or those carefully not recorded
there. I still think C works best on machines where pointers and ints
are the same size :-)

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