This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Optimize callers using nonnull attribute


On Fri, Oct 11, 2013 at 04:21:04PM +0200, Marc Glisse wrote:
> On Fri, 11 Oct 2013, Jakub Jelinek wrote:
> 
> >OT, do you plan to define ATTRIBUTE_RETURNS_NONNULL for
> >GCC_VERSION >= 4009 in ansidecl.h and use it on the various xmalloc
> >etc. prototypes?
> 
> I just read this note in libiberty/concat.c:
> 
>         This function uses xmalloc() which is expected to be a front end
>         function to malloc() that deals with low memory situations.  In
>         typical use, if malloc() returns NULL then xmalloc() diverts to an
>         error handler routine which never returns, and thus xmalloc will
>         never return a NULL pointer.  If the client application wishes to
>         deal with low memory situations itself, it should supply an xmalloc
>         that just directly invokes malloc and blindly returns whatever
>         malloc returns.
> 
> I am afraid that if I add the returns_nonnull attribute to xmalloc
> in include/libiberty.h, it will break this supported use, no? Or is
> this comment out-of-date?

That comment looks weird, because the libiberty/xmalloc.c clearly never
returns NULL, so you'd need to supply a different xmalloc (#define xmalloc
malloc, something else) and I don't see how concat function would handle that
case gracefully.  If
newstr = XNEWVEC (char, vconcat_length (first, args) + 1);
results in NULL newstr, then vconcat_copy will just segfault, it stores at
least '\000' to that unconditionally.

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]