Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!mcsun!unido!mikros!mwtech!martin
From: martin@mwtech.UUCP (Martin Weitzel)
Newsgroups: comp.lang.c
Subject: Re: p[1] vs. *(p+1)
Message-ID: <897@mwtech.UUCP>
Date: 3 Sep 90 21:45:44 GMT
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>
Reply-To: martin@mwtech.UUCP (Martin Weitzel)
Organization: MIKROS Systemware, Darmstadt/W-Germany
Lines: 22

In article <1990Aug31.163647.11121@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>In article <1745@io.UUCP> prs@eng.ileaf.com (Paul Schmidt) writes:
[...]
>>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?
[...]
>Ignoring some syntactic nit-picking, p[1] is *identical* to *(p+1), by
>definition of the C subscripting operation.

And in all flavours of UNIX I've ever used there is a compiler option
(usually -S) which leaves an assembly language file (usually suffixed .s) 
and I've never seen a difference in the assembly source for both
constructs

But note: The fact that *(p+1) can be interchanged with p[1] (and even
with 1[p]) does of course NOT mean that there is no difference between
pointers and arrays. With: T a[10], *ap = a; the machine code produced
for a[1] is DIFFERENT from the code for *(ap+1); but the latter is
the same as for ap[1] and the former is the same as for *(a+1). 
-- 
Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83