Re: in which we present an ugly hack to make sys/queue.h CIRCLEQ work

[Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>]

On 24 Nov, 2013, at 03:37 , Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:
>> [The compiler] also couldn't know if pointers whose types it did know
>> were referring to different members of the same union, perhaps with
>> the union declared in another compilation unit
> 
> The text I have says
> 
>       [#5]  One special guarantee is made in order to simplify the
>       use of unions: if a union contains several  structures  that
>       share  a  common  initial  sequence  (see below), and if the
>       union object currently contains one of these structures,  it
>       is  permitted  to  inspect the common initial part of any of
>       them anywhere that a declaration of the  completed  type  of
>       the union is visible.  Two structures share a common initial
>       sequence if  corresponding  members  have  compatible  types
>       (and, for bit-fields, the same widths) for a sequence of one
>       or more initial members.
> 
> Note that the completed union declaration must be visible for this
> exemption to apply, so as I read it the part after the last comma of
> the quote I opened this mail with is wrong....

Ahh, I misremembered that.  Since this misunderstanding was the basis
for thinking it might be okay to access objects through different structure
pointers as long as the member types matched what was stored, and since
I know of no other part of the standard which would allow this, I can
see why the compiler could choose to treat this as illegal when no
union is visible.  I guess that means the TAILQ macros really are an
accident waiting to happen.

That also makes it clear that, in the CIRCLEQ case, when the pointers
compare equal then any use of both the pointers to access members would
be out-of-spec aliasing.  The comparison being deleted is in fact
surrounded by code which uses the both pointers, so I can see why
the compiler might be suspicious enough to warn about it, but the
only actual aliased access is in a branch of the if()s the comparison
would be correctly avoiding if the code were generated.  It seems like
the optimizer has moved from requiring that code not do anything which
isn't explicitly allowed by the standard (the TAILQ case) to requiring
code not do things which the standard explicitly allows but which may,
in some circumstance, not be perfectly portable.

I think getting rid of uses of the CIRCLEQ macros was the right thing
to do in any case, since code which works like that doesn't need to
exist.  I'm not sure that that TAILQ macros are the best answer
to the problem, though.

Dennis Ferguson