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
