Path: utzoo!attcan!uunet!oddjob!uwvax!umn-d-ub!rutgers!tut.cis.ohio-state.edu!cwjcc!hal!ncoast!allbery
From: allbery@ncoast.UUCP (Brandon S. Allbery)
Newsgroups: comp.sources.d
Subject: Re: Mea Culpa Re: Something's Broken: was ... Re: tgetent
Message-ID: <12083@ncoast.UUCP>
Date: 1 Aug 88 22:58:44 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> <19964@watmath.waterloo.edu>
Reply-To: allbery@ncoast.UUCP (Brandon S. Allbery)
Followup-To: comp.sources.d
Distribution: comp
Organization: Cleveland Public Access UN*X, Cleveland, Oh
Lines: 91

As quoted from <19964@watmath.waterloo.edu> by rwwetmore@grand.waterloo.edu (Ross Wetmore):
+---------------
| >:  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.
+---------------

And in the middle of page 98, discussing the same code...

"Any pointer may be meaningfully compared for equality or inequality with
NULL.  But all bets are off if you do arithmetic or comparisons with pointers
pointing to different arrays.  If you're lucky, you'll get obvious nonsense
on all machines.  If you're unlucky, your code will work on one machine but
collapse mysteriously on another."

Sounds like K&R disagree with you....

+---------------
|   K&R also says that the result of pointer arithmetic is an int. And
+---------------

Where, pray tell?

+---------------
| any implementation of standard C functions I have ever seen has things
| like strlen(), sizeof() ... returning an int-sized value. Note that
+---------------

A bad habit, it should properly be something like memsize_t which on many
BUT NOT ALL machines may be (int).  (Compare large-model 80286 where strlen()
may conceivably have to return a (long), and it will break! because of the
cavalier attitude toward pointer/integer conversion held by many programmers.)

Before you start in about how it's standard so it must be right, tell me how
many Berkeley programs assume that *((char *) 0) == '\0' instead of following
the rule that that address is supposed to be outside the process's address
space?

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

First you say the language specs are broken, then you say they are correct?
Or are you trying to pass the old "all the world's a VAX" argument to us
under new guise?  I refuse to believe that C is *supposed* to be Vax-only,
I prefer to believe K&R.

+---------------
| there. I still think C works best on machines where pointers and ints
| are the same size :-)
+---------------

I think C works best when you use it properly.  Funny, but when you *do* do
so, your programs will run anywhere.

Please note that without some means of getting the proper sizes of things,
the compiler *cannot* make the right decisions -- it can't read your mind
to find out that strlen() takes a (char *), it has to have ANSI prototypes
added so you can tell it about "memsize_t strlen(const char *)".  --And
please note the type I used, having it return (int) is identical to all the
other pointer/integer problems we've been discussing.  This *is* a short-
coming, but if you cast things to work around it things work fine.

I use C with the assumption that that is the way things are supposed to work;
given the possibility of "varargs" functions, not even ANSI prototyping will
solve all your problems.  Consider `execl("/bin/foo", "foo", "bar", 0)'
under 80286 large model.  You can't describe it under ANSI prototypes -- or
any other prototyping system unless you put so many constraints on function
arguments that e.g. printf() won't work any more.  And it will assuredly
drop core.  C *requires* that you specify the argument types because it
allows you to have functions change their expected argument lists on the fly
(compare printf again).  Moreover, done correctly according to the language
rules varargs *does* seem to work on all systems -- because of this
wonderful generality.

++Brandon
-- 
Brandon S. Allbery, uunet!marque!ncoast!allbery			DELPHI: ALLBERY
	    For comp.sources.misc send mail to ncoast!sources-misc