[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Check malloc result in getopt_long

From: Pádraig Brady
Subject: Re: [PATCH] Check malloc result in getopt_long
Date: Mon, 16 Feb 2015 20:57:00 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

On 16/02/15 20:06, Tobias Stoeckmann wrote:
> In contrast to glibc's getopt implementation, this one uses malloc instead
> of alloca. While in general this is a good idea, malloc returns NULL in
> case of error, therefore the return value should be checked.
> The fprintf statements are copied from the same source file; I am rather
> indifferent about the error message.
> Using coreutils' ls (I verified that gnulib's getopt is used on my system):
> tobias:~/git/coreutils$ ulimit -Sv 4226
> tobias:~/git/coreutils$ ./src/ls --t
> Segmentation fault

Yes we shouldn't segfault.
That change came with 

> With this patch:
> tobias:~/git/coreutils$ ./src/ls --t
> ./src/ls: out of memory, dropping option 'time' while resolving ambiguity
> ./src/ls: out of memory, dropping option 'time-style' while resolving 
> ambiguity
> ./src/ls: option '--tabsize' requires an argument
> Try './src/ls --help' for more information.

I'm not sure it's generally worth proceeding in OOM conditions
unless there are clear fall backs.  It would be nice to depend on xalloc
and just call xmalloc(). Could this suffice?

  #ifdef _LIBC
  struct option_list *newp = alloca (sizeof (*newp));
  struct option_list *newp = xmalloc (sizeof (*newp));


reply via email to

[Prev in Thread] Current Thread [Next in Thread]