Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!kddlab!titcca!sragwa!wsgw!socslgw!diamond!diamond
From: diamond@diamond.csl.sony.junet (Norman Diamond)
Newsgroups: comp.lang.c
Subject: Re: A nice macro
Message-ID: <10420@socslgw.csl.sony.JUNET>
Date: 23 Jun 89 03:00:13 GMT
References: <2784@solo8.cs.vu.nl> <13788@haddock.ima.isc.com>
Sender: news@csl.sony.JUNET
Reply-To: diamond@csl.sony.junet (Norman Diamond)
Organization: Sony Computer Science Laboratory Inc., Tokyo, Japan
Lines: 32

In article <2784@solo8.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes:
>>C arrays always begin with subscript 0. ... the solution below seems so
>>straightforward:
>>	bar	_foo[HIGH - LOW + 1];
>>	#define		foo		(_foo - LOW)

In article <13788@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes:

>If LOW <= 0 <= HIGH, no problem.

Well, as long as LOW <= 0 and LOW <= HIGH.  The latter is trivially a
requirement of all languages' array support.  This solution also works
for LOW == -5 and HIGH == -3.

>But this is not portable if you're trying to emulate, say, origin-1
>arrays (LOW==1), since the expression (_foo-1) could be >outside your
>address space.

True indeed.  The entire expression would yield a valid location
(except when the program really does have a subscript error),
e.g. foo[i] == *((_foo-LOW)+i) would be legal if the compiler were
permitted to rewrite the expression as *(_foo+(i-LOW)).

Looks like ANSI has standardized existing practice once again, by
forbidding compilers from making such a rearrangement.  If permitted,
maybe this would have become a quality-of-implementation issue.

--
Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.jp@relay.cs.net)
 The above opinions are claimed by your machine's init process (pid 1), after
 being disowned and orphaned.  However, if you see this at Waterloo, Stanford,
 or Anterior, then their administrators must have approved of these opinions.