https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103964
--- Comment #7 from Ilya Maximets <i.maximets at ovn dot org> ---
(In reply to Jakub Jelinek from comment #6)
> What is the reason why OVS (and kernel) doesn't use 2 variables, one for the
> iterator that is a pointer to the prev/next structure only and one assigned
> e.g. in the condition from the iterator that is used only when it isn't the
> start?
> At least if targetting C99 and above (or C++) one can declare one of those
> iterators in the for loop init expression...
The problem is that we need 2 variables and one of them need to be accessible
outside of the loop. And I don't think it is possible to declare one variable
and only initialize another one. So, we'll have to ask users of the FOR_EACH
macro to declare an extra dummy variable, AFAICT. And we'll also need to have
an extra check outside of the loop before calling ovs_list_insert in our
example.
So, basically, both variables has to be accessible outside of the loop.
Or do you know how to avoid this?
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?
If we can do that, then we can maybe avoid introduction of dummy variables
by re-working the loop to only use uintptr_t operations. Inside the loop
the pointer is always valid, so that should not be a problem (will it?).
Outside of the loop we'll have to use the uintptr_t arithmetic if it's
possible to have a pointer to a non-object (e.g. 'start' with an offset),
but programmer should know that. We will still have to manually re-check
a lot of existing code. For now I don't see the solution that will allow
us to avoid manual re-checking, unfortunately.
