Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!sri-spam!ames!oliveb!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.lang.c
Subject: Re: Writing readable code
Message-ID: <22766@sun.uucp>
Date: Mon, 6-Jul-87 23:51:45 EDT
Article-I.D.: sun.22766
Posted: Mon Jul  6 23:51:45 1987
Date-Received: Wed, 8-Jul-87 06:23:42 EDT
References: <1158@copper.TEK.COM> <6858@auspyr.UUCP> <17171@cca.CCA.COM> <4170@teddy.UUCP>
Sender: news@sun.uucp
Lines: 62

> I don't know, I think this is defensible.  The reason that Microsoft did
> this was so that UNIXisms like:
> 
>    execl(a, b, c, NULL);
> 
> Continue to work even on the bizzare 8086 architecture.

1) This is NOT a "UNIXism".  There are UNIX implementations on which this
does NOT work.

2) The 8086 architecture may be bizarre, but this doesn't have a lot
to do with pointers and integers not being the same size.  There is
at least one 68000 C implementation on a UNIX system that provides
16-bit "int"s and 32-bit pointers, and *this* is defensible as well,
given the 68000 and 68010's incomplete support for 32-bit arithmetic.
(On balance, going with 16-bit "int"s on a 680[01]0, especially in a
UNIX system, may not be the right choice, given that:

	1) the maximum value representable in an "int", in pre-ANSI C
	   implementations, is the maximum size of an object and the
	   largest value you can use as a size for "malloc" *OR*
	   "realloc"

and

	2) the 68020 makes it less of a win to have 16-bit "int"s, so
	   you'd either have to sacrifice binary compatibility when
	   upgrading, throw in hacks to make it work, or hobble the
	   68020

but going with 16-bit "int"s is certainly not INdefensible.)

3) There are probably some architectures that most people would
consider more bizarre than the 8086, for which a C implementation
would make sense, but where

	1) not all pointers are the same size

or

	2) null pointers are NOT represented as a string of
	   zero-valued bits

and, as such, on which you MUST properly cast null pointers when
passing them as arguments.  Defining NULL as 0L may act as a
Band-Aid(TM) for some architectures, but it may merely postpone the
day of reckoning in some cases.  One might as well do it right in the
first place....

> I realize that this is strictly incorrect (NULL should be cast to
> (char *)), but a lot of existing code depends on this behavier.

It's not a question of '"strictly" incorrect', it's a question of
"incorrect".  There was some code in 4.1BSD that "depended" on
location 0 containing a byte with a value of zero, but, well, that
code doesn't work everywhere and has to be fixed.  There may be cases
where contorting the implementation to cater to bad code causes more
problems than it solves.  And if you don't supply negative
reinforcement, some bad habits are never unlearned.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com