Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site fortune.UUCP
Path: utzoo!watmath!clyde!floyd!harpo!ihnp4!fortune!rpw3
From: rpw3@fortune.UUCP
Newsgroups: net.lang.c
Subject: Re: Re: sri-arpa.189 re: read(fd,&y,size - (nf)
Message-ID: <2896@fortune.UUCP>
Date: Thu, 29-Mar-84 04:04:25 EST
Article-I.D.: fortune.2896
Posted: Thu Mar 29 04:04:25 1984
Date-Received: Fri, 30-Mar-84 02:35:54 EST
Sender: notes@fortune.UUCP
Organization: Fortune Systems, Redwood City, CA
Lines: 26

#R:iedl02:-171400:fortune:16200022:000:869
fortune!rpw3    Mar 28 22:16:00 1984

Historical (I hope!) trivia:

Fortuitously for many hackers (which doesn't make it "right" or "good"),
the 36-bit pattern of all zeroes (integer 0) on a PDP-10 just so happens
to be a "legal" byte-pointer. It points to a field "zero" bits wide which
is right-justified in accumulator zero. If you do a load-byte (LDB) on it,
you will get a zero. If you do a deposit-byte (DPB) the bits will go into
the bit-bucket in the sky and nothing is changed.

Also, any pointer whose "position offset" is 36 or greater (63 max) is
a similar "/dev/null", even with a non-zero byte size.

	DPB	T1,[440700,,1234]	; expensive no-op (O'44' == 36)
	LDB	T2,[440700,,1234]	; slow way to clear T2

Like I said, trivia.

Rob Warnock

UUCP:	{sri-unix,amd70,hpda,harpo,ihnp4,allegra}!fortune!rpw3
DDD:	(415)595-8444
USPS:	Fortune Systems Corp, 101 Twin Dolphin Drive, Redwood City, CA 94065