[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bison 3.5.92 on IRIX
From: |
Akim Demaille |
Subject: |
Re: Bison 3.5.92 on IRIX |
Date: |
Sun, 31 May 2020 08:24:22 +0200 |
Hi Bruno,
> Le 3 mai 2020 à 17:17, Bruno Haible <bruno@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!