Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!gatech!usenet.ins.cwru.edu!abvax!iccgcc!browns
From: browns@iccgcc.decnet.ab.com (Stan Brown)
Newsgroups: comp.lang.c
Subject: Re: Careful "for" Loops
Message-ID: <3942.27edea2f@iccgcc.decnet.ab.com>
Date: 25 Mar 91 17:16:47 GMT
References: <MCDANIEL.91Mar19124111@dolphin.adi.com> <15524@smoke.brl.mil> <1991Mar21.181807.24059@ism.isc.com>
Followup-To: comp.lang.c
Lines: 32

In article <1991Mar21.181807.24059@ism.isc.com>, willcr@bud.sos.ivy.isc.com (Will Crowder) writes:
> On a somewhat related note, the ANSI C standard guarantees that the address of
> the element one past the end of an array is representable and won't overflow.
> This makes loops like
> 
> {
> 	int a[10];
> 	int *p, *q;
> 
> 	/* point q and at end a */
> 
> 	q = &a[sizeof a / sizeof a[0]];
> 
> 	for (p = a; p != q; p++)
> 		useful_work_goes_here();
> }
> 
> work properly.  [The (sizeof a / sizeof a[0]) expression keeps the explicit 
> knowledge of the size of the array in its declaration.]  The implementation
> must place the array a such that &a[10] is representable and will not
> overflow.

I use
        for (p=a; p<a; p++)
Then if my loop also increments p, the loop still terminates.

(Yes, I know my loop _shouldn't_ increment p, but sometimes I
make coding errors.)

My opinions are mine:  I don't speak for any other person or company.
                   email (until 91/4/30): browns@iccgcc.decnet.ab.com
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA    +1 216 371 0043