This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Optimize callers using nonnull attribute
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Marc Glisse <marc dot glisse at inria dot fr>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 11 Oct 2013 16:31:30 +0200
- Subject: Re: Optimize callers using nonnull attribute
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 02 dot 1310070016540 dot 15069 at stedding dot saclay dot inria dot fr> <CAFiYyc3o9ZYNWgfNOpL6VjD84doj6Mh81USALdRF1N967M5iOA at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1310071517260 dot 21427 at stedding dot saclay dot inria dot fr> <20131011125022 dot GR30970 at tucnak dot zalov dot cz> <alpine dot DEB dot 2 dot 10 dot 1310111615160 dot 4113 at laptop-mg dot saclay dot inria dot fr>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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