Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!decvax!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.lang.c
Subject: Re: c programming style - READ THIS
Message-ID: <2460@sun.uucp>
Date: Sun, 21-Jul-85 17:35:24 EDT
Article-I.D.: sun.2460
Posted: Sun Jul 21 17:35:24 1985
Date-Received: Wed, 24-Jul-85 06:28:10 EDT
References: <11570@brl-tgr.ARPA> <935@teddy.UUCP> <1286@uwmacc.UUCP> <2439@sun.uucp> <90@rtp47.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 22

> In an otherwise OK article, Guy Harris says:
> 
> >        1) The only operation in C that adds an integer to the integer
> >           with the same bit pattern as a given pointer and produces a
> >           pointer value with the same bit pattern as the result is
> >
> >           (pointer_type) ((int)pointer + integer_value)
> >
> >        Guy Harris
> 
> This turns out not to be the case.  The expression "(int)p" where p is a
> pointer does not in any way, shape, or form guarantee to yeild an
> integer with the "same bits" as the pointer p.

Yes, I knew that (having worked for N years on a machine where "int" was 16
bits and pointers were 32 bits), but adding in code to make it work
correctly and explain it to people who don't understand that adding an
integer to a pointer makes the pointer advance by that integer number of the
storage objects pointed to by the pointer, not that integer number of
machine storage units, would probably have totally confused them.

	Guy Harris