Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!apple!mips!daver!tscs!tct!chip From: chip@tct.uucp (Chip Salzenberg) Newsgroups: comp.lang.c Subject: p[1] vs. *(p+1) Message-ID: <26D952F5.4E44@tct.uucp> Date: 27 Aug 90 17:05:56 GMT References: <1881@jura.tcom.stc.co.uk> <3603@goanna.cs.rmit.oz.au> <1990Aug24.064203.20942@icc.com> Organization: Teltronics/TCT, Sarasota, FL Lines: 18 According to cbp@icc.com (Chris Preston): > For instance, I am told that the following is a problem in Kanji > > char p[10]; /* xscc provides for allowing twenty bytes as needed in Kanji */ > > *(p+1)='x'; /* this is the next byte, and an error */ > p[n+1]='x'; /* this is the next _character_ and ok */ Just so no one panics: Unless I misunderstand Chris Preston's example, this bit of code is not a harbinger of things to come, but rather an artifact of a broken compiler. 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. Since time immemorial, "*(a+b)" and "a[b]" have been synonymous, and such is C today. -- Chip Salzenberg at Teltronics/TCT ,