On Wed, Mar 11, 2015 at 10:54 AM, Jason Ekstrand <ja...@jlekstrand.net> wrote: > __next and __prev are pointers to the structure containing the exec_node > link, not the embedded exec_node. NULL checks would fail unless the > embedded exec_node happened to be at offset 0 in the parent struct. > > v1 Reviewed-by: Kenneth Graunke <kenn...@whitecape.org> > v1 Reviewed-by: Connor Abbott <cwabbo...@gmail.com> > > v2: Jason Ekstrand <jason.ekstr...@intel.com>: > Use "(__node)->__field.next != NULL" to check for the end of the list > instead of the "&__next->__field != NULL". The former is far more > obviously correct as it matches what the non-safe versions do. The > original code tried to avoid any use of __next as the client code may > delete it during its execution. However, since the looping condition is > checked after the iteration clause but before the client code is > executed, we know that __node is valid during the looping condition. > > Signed-off-by: Jason Ekstrand <jason.ekstr...@intel.com> > --- > src/glsl/list.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/src/glsl/list.h b/src/glsl/list.h > index ddb98f7..25fc85c 100644 > --- a/src/glsl/list.h > +++ b/src/glsl/list.h > @@ -684,7 +684,7 @@ inline void exec_node::insert_before(exec_list *before) > exec_node_data(__type, (__list)->head, __field), \ > * __next = \ > exec_node_data(__type, (__node)->__field.next, __field); \ > - __next != NULL; \ > + (__node)->__field.next != NULL; \
Tab here. With that fixed: Reviewed-by: Matt Turner <matts...@gmail.com> _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
