Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!labrea!aurora!ames!sdcsvax!ucbvax!jade!eris!mwm
From: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer)
Newsgroups: comp.sys.amiga
Subject: Re: Manx C
Message-ID: <4628@jade.BERKELEY.EDU>
Date: Wed, 31-Dec-69 18:59:59 EDT
Article-I.D.: jade.4628
Posted: Wed Dec 31 18:59:59 1969
Date-Received: Sat, 8-Aug-87 19:22:09 EDT
References: <4540@jade.BERKELEY.EDU> <1836@vax135.UUCP> <4595@jade.BERKELEY.EDU> <3199@zen.berkeley.edu> <17827@amdcad.AMD.COM> <3211@zen.berkeley.edu>
Sender: usenet@jade.BERKELEY.EDU
Reply-To: mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer)
Distribution: comp
Organization: Missionaria Phonibalonica
Lines: 88
Keywords: look at the assembly.

In article <3211@zen.berkeley.edu> waterman@cory.Berkeley.EDU.UUCP (T.S. Alan Waterman) writes:
<     What I don't get is this-- (!ptr) seems more straightforward,
<     you never have to worry about types, and it makes smaller code
<     than (ptr == 0) anyway.  Why use the second expression? (with
<     pointers, at least.)

No, !ptr is *not* more straightforward. I read that as "if ptr is
false". Huh? Pointers aren't booleans - they don't take on true or
false values. On the other hand, !ptr can be read as "if ptr not
valid", which makes some sense. I don't like it, but I'm not dogmatic
about it.

That !ptr generates smaller code on Manx is probably related to Manx
not handling "ptr == 0" correctly. On a compiler that does things
right (4.3BSD pcc), I put in:

	main() {
		char	*x ;
		if (x == 0) ;
		if (!x) ;
		}

and get out (for the important part):

	L15:
		tstl	-4(fp)
		jneq	L16
	L16:
		tstl	-4(fp)
		jneq	L17
	L17:

In other words, you get the exact same code from either case. I expect
Lattice to do the same, and will try to remember to test it when I get
home.

<   I really don't want to turn this into a war, but I have to disagree, at
<least in principle. The comparison operator '==' only applies (and I think
<only should apply) if the objects being compared ARE OF THE SAME TYPE!!!!

You're welcome to disagree. But if you implement a compiler that
enforces that view, please don't call it a C compiler. The standards
quite clearly states that 0 is magic, and turns into a pointer in
expressions involving pointers. A compiler that behaves otherwise is
either buggy, or not a C compiler. The reasons for doing things the
way C does them will be covered below.

<If your 0 happens to be of the same type as your pointer, fine; but, on the
<other hand, if it's not, something's going to get type converted.

The constant 0 is of type int. No questions asked. In expressions
involving poiners, the standards state that it will be converted to a
null pointer. That pointer is not necessarily all 0 bits, it's just
something that no pointer to an object can be. On some architectures,
the pointer with all zero bits can point to a valid object, so you
have to use some other value for the null pointer. 0 gets turned into
that value by the compiler.

<If both arg's are numeric, this wont be a problem, because the 'bigger'
<type will win, and the other one will get converted (try comparing int's
<and reals).  Pointers, though, confuse the poor compiler, because it's not
<sure what you really meant to do. Try comparing a pointer and a floating-point
<real.

But there isn't a floating point value that can be implicitly coerced
into a pointer, so there is no case where doing such a comparison
makes sense. That kind of construct isn't portable. Your argument for
integer comparison is correct, except for the special case of 0.

<   Before you flame, I'll admit that it makes no sense to do that. But then,
<it really doesn't make sense to compare a pointer with a constant of a different
<size, either, becuase the compiler doesn't (but probably should) know
<what to do with it.

But people writing code shouldn't have to know how long pointers on
their machine are! It makes the code less portable. It also creates
nightmares on machines with pointers of different lengths. And pity
the poor person who's writing code on a machine that has a pointer to
some type which is longer than any integral type (yes, such machine
exist).


	<mike
--
Take a magic carpet to the olden days			Mike Meyer
To a mythical land where everybody lays			mwm@berkeley.edu
Around in the clouds in a happy daze			ucbvax!mwm
In Kizmiaz ... Kizmiaz					mwm@ucbjade.BITNET