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 <[email protected]> > > --- > > 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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
