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

Ferry Huberts mailings at hupie.com
Tue Jul 5 00:20:57 PDT 2011



On 07/04/2011 07:29 PM, 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;
> 

NULL and '\0' have different semantics:

NULL: undefined
'\0': defined, but empty

so mixing would be bad because it breaks semantics


grtz

-- 
Ferry Huberts


More information about the xorg-devel mailing list