That's disgusting. If it's important to know where it failed, that's
why you call the regular funciton, check the error and say something
intelligent. Then it's easy to look at the code and know it's doing
the right thing, rather than having to wade through some macro and
gccisms. bleah.
I'd f
On Sun, Dec 16, 2012 at 01:01:49PM -0700, Theo de Raadt wrote:
> > know exactly where the memory allocation fails since the error messages
>
> I hate xstrdup() and xcalloc() for exactly that reason. You don't
> know why it failed.
Actually, you can make them macros using all that underscore gcc
> I'm not opposed to introducing xstrdup() and xcalloc() to do the same
> thing, though I think one advantage of the current method is that we
> know exactly where the memory allocation fails since the error messages
> are very specific, e.g. "no memory for unpriv_ibuf" vs. "xcalloc: out of
> memor
On Thu, Dec 13, 2012 at 12:07:42PM +0100, Joerg Zinke wrote:
>
> Am 11.12.2012 um 04:12 schrieb Lawrence Teo :
>
> > There are a number of calloc() and strdup() calls in the
> > apply_defaults() and clone_lease() functions whose return values are not
> > checked. If they happen to return NULL, d
Am 11.12.2012 um 04:12 schrieb Lawrence Teo :
> There are a number of calloc() and strdup() calls in the
> apply_defaults() and clone_lease() functions whose return values are not
> checked. If they happen to return NULL, dhclient will segfault.
>
> This diff checks their return values and does
There are a number of calloc() and strdup() calls in the
apply_defaults() and clone_lease() functions whose return values are not
checked. If they happen to return NULL, dhclient will segfault.
This diff checks their return values and does some cleanup if they
return NULL. The diff also ensures
