http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46488
--- Comment #22 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2010-11-29
12:09:30 UTC ---
> The pointers are constructed explicitly to never be dereferenced, only
> compared for equality; if a dereference exists it would be a bug, but
> I don't see one.
APR_RING_SPLICE_HEAD does such a dereference as far I can see:
#define APR_RING_SPLICE_HEAD(hp, ep1, epN, elem, link) \
APR_RING_SPLICE_AFTER(APR_RING_SENTINEL((hp), elem, link), \
(ep1), (epN), link)
#define APR_RING_SPLICE_AFTER(lep, ep1, epN, link) do { \
APR_RING_PREV((ep1), link) = (lep); \
APR_RING_NEXT((epN), link) = APR_RING_NEXT((lep), link); \
APR_RING_PREV(APR_RING_NEXT((lep), link), link) = (epN); \
APR_RING_NEXT((lep), link) = (ep1); \
} while (0)
#define APR_RING_NEXT(ep, link) (ep)->link.next
#define APR_RING_PREV(ep, link) (ep)->link.prev
> In the absence of such a smoking gun, can an C99 aliasing issue occur merely
> in handling pointer equivalence?
That would be a real compiler bug. :-)
You seem to be quite familiar with the httpd code. Can you pinpoint what is
miscompiled exactly in ap_core_input_filter or ap_core_output_filter? I'm not
saying that the miscompilation comes from this strict aliasing issue, only that
it might at this point.
