https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103964
--- Comment #12 from Ilya Maximets <i.maximets at ovn dot org> ---
> (In reply to Ilya Maximets from comment #7)
> > One thing that is not clear to me is if the following code has an UB or not:
> >
> > struct member* pos;
> > struct ovs_list start;
> >
> > pos = (struct member *)(void*)((uintptr_t)(&start) - 64);
> > ovs_list_insert((void *)((uintptr_t)pos + 64), &member->elem);
> >
> > ?
> >
> > This code works fine. Basically, the question is: can we cast and store
> > the random (aligned) integer to a pointer type, if we're not going to
> > perform any kind of pointer arithmetic (using the integer arithmetic for
> > the ovs_list_insert) nor dereference it, unless it points to the actual
> > valid object?
>
(In reply to Richard Biener from comment #8)
> That should be OK, yes.
(In reply to Jakub Jelinek from comment #9)
> It still creates a pointer out of something that doesn't point to such an
> object or points to some unrelated one, doesn't necessarily have sufficient
> alignment etc., so I think it is UB too, but perhaps the compiler at least
> now will handle it the way you expect.
I think, we'll try to re-write the loops to have 2 distinct variables, but
for the case we'll need the uintptr_t solution too as a backup plan, I have
one more question. How bad is this:
struct member* pos;
struct ovs_list start;
pos = (struct member *)(void*)((uintptr_t)(&start) - 64);
struct ovs_list *list;
list = (typeof(&pos->elem))(void *)((uintptr_t)pos + 64);
?
Basically, how much undefined is the 'typeof(&pos->elem)' construction?
(I just tried to prototype the part of the solution and I found that I need
a correct cast inside the macro, so the code will not look way too ugly.)
In general, I think, typeof() should not care about the actual value
of a pointer, but as we concluded the '&pos->elem' evaluation itself can
be harmful, so I don't know.
