Re: Bounds checking, Optimization techniques and undefined behavior

On 06/05/2019 01:15, our esteemed moderator wrote:
> [In the struct { int a,b,c,d; } S example it is my understanding that &S and &S.a
> have to be the same,


Not "the same", as they have different types; but yes, they must
compare equal.


> the four ints have to be in the order declared,


Yes, and they must be "sequentially allocated". Whether that means
the same as "contiguously allocated" [like array members] is not entirely
clear, as the C Standard doesn't define these terms. Structures can contain
padding, in general, but [AFAICT] not in a way that affects this debate.
At least it seems to be the case that &S.a+1 must compare equal to &S.b,
see N1570, section 6.5.9 para 6, and footnote 109; but I can't quite make
even this case watertight.


> and they
> all have the same alignment so it is valid abeit poor form to treat them as
> an array. -John]


For the purposes of pointer arithmetic [and therefore arrays] and
comparison, non-array objects are treated as arrays with a single element.
So &S+0 and &S+1 are valid, though the latter can't be dereferenced;
likewise &S.a+0 and &S.a+1, and they can be compared with &S.b, etc. But
I can see no support in the Standard for &S.a+2 being anything other than
UB; it points neither to "the" element of S.a, nor one past. That's even
though [or if!] &S.a+1 == &S.b and &S.b+1 == &S.c; Section 6.5.6, paras
8 and 9. As George Neuner says, if you want to use S also as an array,
then you should have declared it as a union.


In Real Life, you will surely get away with such things, and with
much technically undefined pointer arithmetic that temporarily strays
outside an array [without dereference]. It's sanctioned by dubious custom,
but not by the Standard. [Yes, I've done it myself. I'm suitably ashamed
and am hereby rapped on the knuckles.]


--
Andy Walker,
Nottingham.

Return to the comp.compilers page.
Search the comp.compilers archives again.