Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 ggr 10/10/85; site bentley.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!bentley!kwh
From: kwh@bentley.UUCP (KW Heuer)
Newsgroups: net.lang.c
Subject: Re: *p++ = *p results?
Message-ID: <678@bentley.UUCP>
Date: Mon, 31-Mar-86 16:19:40 EST
Article-I.D.: bentley.678
Posted: Mon Mar 31 16:19:40 1986
Date-Received: Wed, 2-Apr-86 02:12:13 EST
References: <312@imagen.UUCP> <258@necis.UUCP>, <2412@utcsri.UUCP>
Organization: AT&T Bell Laboratories, Liberty Corner
Lines: 16

In article <2412@utcsri.UUCP> utcsri!greg (Gregory Smith) writes:
>[Some] operators have a defined order of execution:
>	if( p != NULL   &&   *p == What_I_am_looking_for )....
>Evaluating *p will crash the program if p==NULL, but since the && operator
>behaves the way it does, this will never happen.

Actually, on many machines dereferencing NULL doesn't crash the program,
it just returns an uninteresting result -- usually causing a program
crash much later, after which it's difficult to track down the bug.

On the 3b2, neither text or data space is anywhere near address zero,
page zero has no interesting contents, yet it is readable.  Apparently
this is so that programs that dereference NULL can be ported!  (I wish
they'd at least make it a loader option, so it could be turned off...)

Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint