Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!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: <22642@sun.uucp>
Date: Fri, 3-Jul-87 07:14:32 EDT
Article-I.D.: sun.22642
Posted: Fri Jul  3 07:14:32 1987
Date-Received: Sat, 4-Jul-87 13:17:44 EDT
References: <1158@copper.TEK.COM> <6858@auspyr.UUCP> <17171@cca.CCA.COM> <1681@kontron.UUCP>
Sender: news@sun.uucp
Lines: 30

> Or even the same machine.  For example, if you are compiling in small
> model on the 8086 with the Microsoft compiler:
> 
> 	#define NULL 0
>         
> but in large model:
> 
> 	#define NULL 0L
>         
> Depending on how you are using it, the results may come out the same --
> but relying on the compiler to notice that are comparing int and long
> (in large model) is a very poor practice.

Where are "int"s and "long"s being compared here?  Ron Natalie was
referring to constructs such as

	char *p;
	if (p == NULL)

and in this case a *pointer*, which is a totally different animal
from an "int" or a "long", is being compared with NULL, which is
generally an "int" except on some implementations that cheat and make
it a "long".  Any correct C compiler will generate a 32-bit
comparison in the large model for the code above (or whatever
comparison tests *all* the bits in the pointer that are actually
used; if, say, 8 of those bits are not considered part of the
pointer's value, they need not be compared).
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com