Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!homxb!mtuxo!mtune!codas!ateng!chip
From: chip@ateng.UUCP (Chip Salzenberg)
Newsgroups: comp.lang.c
Subject: Re: Swap
Message-ID: <162@ateng.UUCP>
Date: 22 Jan 88 16:49:18 GMT
References: <3819@sigi.Colorado.EDU> <5080013@hpfcdc.HP.COM> <7120@brl-smoke.ARPA> <3203@bunker.UUCP> <661@l.cc.purdue.edu>
Reply-To: chip@ateng.UUCP (Chip Salzenberg)
Organization: A T Engineering, Tampa, FL
Lines: 30

In article <661@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>
>	a ^= b;
>	b ^= a;
>	a ^= b;
>
>I have used it on various machines.  Of course, a particular implementation
>of C might not let you use it on pointers or floats; this is a defect in C,
>as there is no way the hardware can give the wrong answer(s).

Sorry, but this is not a "defect in C".  This is a reflection of the fact
that pointers and floats may not (portably) be treated as arbitrary bit
strings.

For example: the '286 and '386, in protected mode, require that any value
loaded into a segment register be a valid segment selector.  Therefore:

	 if   a and b are "far" (segment+offset) pointers,
	and   (a ^ b) is an invalid pointer (probable),
	and   a is a register variable (possible),
       then   "a ^= b", if it compiled at all, will cause a trap.

Please repeat after me:

               "Pointers are not just integers in disguise."

-- 
Chip Salzenberg                 UUCP: "{codas,uunet}!ateng!chip"
A T Engineering                 My employer's opinions are a trade secret.
       "Anything that works is better than anything that doesn't."