Hi Bruno, > Le 3 mai 2020 à 17:17, Bruno Haible <br...@clisp.org> a écrit : > > There are a couple of GCC warnings on IRIX (CC="gcc -mabi=n32"): > > 2) > ../src/fixits.c: In function `fixits_run': > ../src/fixits.c:129: warning: dereferencing type-punned pointer will break > strict-aliasing rules > > Modern C rules wants f to be a 'const void *'. Inside the loop body, > you can cast f to 'fixit const *' without danger.
So I had installed this: - fixit const *f = NULL; + void const *p = NULL; gl_list_iterator_t iter = gl_list_iterator (fixits); - while (gl_list_iterator_next (&iter, (const void**) &f, NULL)) + while (gl_list_iterator_next (&iter, &p, NULL)) { + fixit const *f = p; Today we have more occurrences of this pattern that we have to fix, but some of these items need the pointer to point to a non-const value, so we need a const void * pointer, and still a cast. Would you accept a macro, say gl_list_mutable_iterator_next, where we would pass a void** instead of const void**? Of course mutable_iterator gives the impression that it's the iterator which is mutable, but an iterator must so obviously be mutable that I don't think it would be much of an issue, and it's quite symmetrical with const_iterator. It might have been less surprising to have the current gl_list_iterator_next be about mutable values and use gl_list_const_iterator_next for readonly iteration, but it's too late. Also, in gnulib, I found this in gl_list.hh: /* If there is a next element, stores the next element in ELT, advances the iterator and returns true. Otherwise, returns false. */ bool next (ELTYPE *& elt) { return gl_list_iterator_next (&_state, reinterpret_cast<const void **>(&elt), NULL); } /* If there is a next element, stores the next element in ELT, stores its node in *NODEP if NODEP is non-NULL, advances the iterator and returns true. Otherwise, returns false. */ bool next (ELTYPE *& elt, gl_list_node_t *nodep) { return gl_list_iterator_next (&_state, reinterpret_cast<const void **>(&elt), nodep); } It is not my understanding that reinterpret_cast protects from type punning issues. Did I miss something? We've had in the past to do something alike in Bison (https://lists.gnu.org/r/bison-patches/2013-01/msg00131.html). Cheers!