[PATCH 02/10] xfree86: NULL option values are technically valid, don't strdup them

[Peter Hutterer]

On Mon, Jul 04, 2011 at 07:29:15PM +0200, walter harms wrote:
> 
> 
> Am 04.07.2011 08:09, schrieb Peter Hutterer:
> > Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
> > ---
> >  hw/xfree86/common/xf86Option.c |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/hw/xfree86/common/xf86Option.c b/hw/xfree86/common/xf86Option.c
> > index 480f386..a3a836f 100644
> > --- a/hw/xfree86/common/xf86Option.c
> > +++ b/hw/xfree86/common/xf86Option.c
> > @@ -340,7 +340,7 @@ pointer
> >  xf86AddNewOption(pointer head, const char *name, const char *val)
> >  {
> >      /* XXX These should actually be allocated in the parser library. */
> > -    char *tmp = strdup(val);
> > +    char *tmp = val ? strdup(val) : NULL;
> >      char *tmp_name = strdup(name);
> >  
> >      return xf86addNewOption(head, tmp_name, tmp);
> 
> maybe "\0" is better here ? i have no clue what is done later with tmp_name
> (possible nothing) but making a valid string pointer here removes the need for
> things like: val ? strdup(val) : NULL;

I think the only case this ever happened was with the CorePointer assignment
that was fixed as part 05/10 of this series. Not sure what other valid
configurations would have this. Nonetheless I'm a bit worried that \0 may
trigger different behaviour than NULL. For example, some input drivers have
if ((s = xf86SetStrOption(...)) conditions which would break if "\0"
was returned.

Cheers,
  Peter