[Bug c/20318] New: RFE: add attribute to specify that a function never returns NULL

[jorton at redhat dot com]

It would be useful to have a function attribute which specifies that the
function never returns NULL.

Currently the GCC 4 snapshots with -O2 -Wall generate ~15 spurious warnings in
the Subversion source code which could be eliminated if a couple of functions
could be marked as never returning NULL.

-- 
   Summary: RFE: add attribute to specify that a function never
returns NULL
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P2
 Component: c
AssignedTo: dnovillo at gcc dot gnu dot org
ReportedBy: jorton at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20318

[Bug middle-end/46488] [4.5 regression] server/core_filters.c from apache httpd 2.2.17 miscompiled at -O3

[jorton at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46488

Joe Orton  changed:

   What|Removed |Added

 CC||jorton at redhat dot com

--- Comment #19 from Joe Orton  2010-11-29 11:02:26 
UTC ---
(In reply to comment #18)
> Using
> 
> #define APR_RING_SENTINEL(hp, elem, link)\
> (struct elem *)((char *)(hp) - APR_OFFSETOF(struct elem, link))
> 
> should be safer wrt strict aliasing.

We changed the macro from that to the current definition to avoid strict
aliasing warnings from gcc:

  http://svn.apache.org/viewvc?view=revision&revision=662299

Does the cast through a char * not have the desired effect of allowing the
pointer to alias any other pointer regardless of type?  That is one of the
exceptions in C99 6.5/par 7.

Why specifically does this result in an C99 aliasing violation anyway?  The
pointers to which this macro evaluates are never dereferenced, only compared
for equality.

[Bug middle-end/46488] [4.5 regression] server/core_filters.c from apache httpd 2.2.17 miscompiled at -O3

[jorton at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46488

--- Comment #21 from Joe Orton  2010-11-29 11:38:44 
UTC ---
Thanks for the explanation.

(In reply to comment #20)
> > Why specifically does this result in an C99 aliasing violation anyway?  The
> > pointers to which this macro evaluates are never dereferenced, only compared
> > for equality.
> 
> I think they are dereferenced by the macro APR_RING_{NEXT,PREV} in some cases.

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.

In the absence of such a smoking gun, can an C99 aliasing issue occur merely in
handling pointer equivalence?

[Bug middle-end/46488] [4.5 regression] server/core_filters.c from apache httpd 2.2.17 miscompiled at -O3

[jorton at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46488

--- Comment #25 from Joe Orton  2010-11-29 14:03:40 
UTC ---
(In reply to comment #22)
> APR_RING_SPLICE_HEAD does such a dereference as far I can see:

You are right, sorry, I had forgotten exactly how this code works.

(In reply to comment #24)
> not really.  But using
> 
> typedef struct elem elem_ __attribute__((may_alias));
> #define APR_RING_SENTINEL(hp, elem, link) \
> (struct elem_ *)((char *)(hp) - APR_OFFSETOF(struct elem, link))
> 
> would be safe wrt strict aliasing (if the pointer is only dereferenced
> directly and not casted to another pointer type before, of course).

I don't think we can guarantee this with the API unchanged; the sentinel
pointer could well be stored in a "struct elem *" pointer.