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