Is &a[NTHINGS] legal

Carl Paukstis carlp at iscuva.ISCS.COM
Sat May 7 06:47:47 AEST 1988


In article <2699 at geac.UUCP> daveb at geac.UUCP (David Collier-Brown) writes:
>In article <1450 at iscuva.ISCS.COM> carlp at iscuva.ISCS.COM ([ME!]) writes:
>>                       .... it is an error to attempt to dereference
>>a[NTHINGS+1].  There must be a valid ADDRESS (or at least simulation of
>>one), so that size calculations will work, mostly, but also so that
>>bound-checking as proposed in the original posting is possible.
>
>  My understanding is that one has to be able to generate the
>address of the last-plus-one'th element of an array:
>	thing a[NTHINGS];
>	...
>
>	if (x < &a[NTHINGS]) ...
>
>  I'm not so sure about NTHINGS+1, which is the last-plus-two'th
>(last-plus-tooth?) element.

I guess it's been at least a week since I last said a[NTHINGS] to
indicate the final element of an array of NTHINGS elements.  I started
programming with FORTRAN IV, which I recall as having 1-based rather than
0-based subscripts.  Old habits die hard.

Of course I really meant to say that it's an error to dereference (is that
the right word, or does that apply only to pointers?) the element
"a[NTHINGS]", which as dave c-b points out is last-plus-one'th element.  I
think my understanding agrees with dave's: &a[NTHINGS] is a valid address,
and pointer arithmetic can be done with it; while a[NTHINGS] is NOT a valid
element and can't be used.  Both &a[NTHINGS+1] and a[NTHINGS+1] are
undefined.

Which is, of course, what doug gwyn was saying in the first place.  I tried
to clarify his statements after I saw some followups which misinterpreted
what he said.  It seems I only added to the confusion.  For this I
apologize, and I will now return to lurking quietly in the shadows...


-- 
Carl Paukstis    +1 509 927 5600 x5321  |"I met a girl who sang the blues
                                        | and asked her for some happy news
UUCP:     carlp at iscuvc.ISCS.COM         | but she just smiled and turned away"
          ...uunet!iscuva!iscuvc!carlp  |                    - Don MacLean



More information about the Comp.lang.c mailing list