[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