Re: PATCH: Do not call xmalloc_failed in expandargv

[Mark Mitchell <mark@codesourcery.com>]

DJ Delorie wrote:
>>xmalloc is in libiberty, and it calls xmalloc_failed when it fails,
>>which itself calls xexit.  That's the source of the idiom; I was
>>just trying to be consistent.
> 
> 
> I don't feel strongly about it.  I bring it up only to cover all
> possibilities.  I guess if you run out of memory in the first
> allocation after main starts, you're screwed anyway.  Er... don't
> expect fputs() to work if you're out of memory at that point; it won't
> be able to allocate stdio buffers.  write(2,...) would be safer, if
> less portable.

xmalloc_failed uses fprintf, which is surely at least as likely as
fprintf to allocate memory.  And, write(2, ...) is also considered
unsafe; we had this argument in the context of libstdc++ a while back.
(Some applications close file descriptor 2, and then open some other
file, which happens to be assigned descriptor 2.)  You can avoid this if
you mandate that all applications using libiberty make sure that file
descriptor 2 is stderr.

Anyhow, it seems weird to change expandargv if we don't change
xmalloc_failed.

> Hmmm... dupargv calls malloc(), not xmalloc().  expandargv calls
> xmalloc(), but that's the only call to xmalloc in that file.  I wonder
> if we're looking at the wrong idiom for this file?

In my original patch, expandargv returned an error code, or, actually,
the name of the file it couldn't read.  IIRC, you asked me to remove
that, so that callers would require as few changes as possible.  In
practice, we're typically going to call expandargv() exactly once, at
the top of main.  Bombing out fatally doesn't seem bad to me in this
case; applications aren't going to be very likely to recover.

It seems like we're worrying about a very low-probability situation.  If
we find an application that really wants to recover from "@foo" being
too big, we can always change expandargv to ignore the "@foo" option as
you suggested, or to return -1, or some such.

Of course, if you do want me to make this change, I will.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304