Newsgroups: comp.lang.c
Path: utzoo!henry
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: p[1] vs. *(p+1)
Message-ID: <1990Aug31.163647.11121@zoo.toronto.edu>
Organization: U of Toronto Zoology
References: <1881@jura.tcom.stc.co.uk> <3603@goanna.cs.rmit.oz.au> <1990Aug24.064203.20942@icc.com> <26D952F5.4E44@tct.uucp> <1745@io.UUCP>
Date: Fri, 31 Aug 90 16:36:47 GMT

In article <1745@io.UUCP> prs@eng.ileaf.com (Paul Schmidt) writes:
>>Any compiler that considers "*(p+1)" and "p[1]" to be different does
>>not comply with the ANSI standard -- or with K&R, for that matter.
>
>So, that means that the compiler must know the size of the elements of
>array p, and that *(p+1) does not add 1 to p, but instead adds
>sizeof(array_element_type) to p?

Although you phrased it a bit poorly, that is correct.  What is the
*meaning* of adding 1 to a pointer?  In C, it means that the pointer
is increased as far as necessary to point to the next array element.
What happens to the actual bit patterns is the compiler's business;
typically this will, indeed, involve adding sizeof(*p) to p, considered
as an integer.

>I must confess that I use p[1] in these cases, and count on the compiler
>to optimize for me.

Ignoring some syntactic nit-picking, p[1] is *identical* to *(p+1), by
definition of the C subscripting operation.
-- 
TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology
OSI: handling yesterday's loads someday|  henry@zoo.toronto.edu   utzoo!henry