Re: [Xen-devel] [PATCH] cmdline: treat hyphens and underscores the same

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 12/6/19 4:42 PM, Jan Beulich wrote:
> On 06.12.2019 17:20, Julien Grall wrote:
>> Hi,
>>
>> On 06/12/2019 16:06, Jan Beulich wrote:
>>> On 06.12.2019 15:46, Julien Grall wrote:
>>>> On 05/12/2019 16:50, Jan Beulich wrote:
>>>>> On 05.12.2019 17:27, Julien Grall wrote:
>>>>>> On 05/12/2019 15:33, Jan Beulich wrote:
>>>>>>> +/*
>>>>>>> + * String comparison functions mostly matching strcmp() / strncmp(),
>>>>>>> + * except that they treat '-' and '_' as matching one another.
>>>>>>> + */
>>>>>>> +static int _strcmp(const char *s1, const char *s2)
>>>>>>
>>>>>> I thought we were trying to avoid new function name with leading _?
>>>>>
>>>>> We're trying to avoid new name space violations. Such are
>>>>> - identifiers starting with two underscores,
>>>>> - identifiers starting with an underscore and an upper case letter,
>>>>> - identifiers of non-static symbols starting with an underscore.
>>>>
>>>> I am not sure to understand why non-static symbols only. This would
>>>> prevent you to use the the non-static symbol if you happen to re-use the
>>>> same name.
>>>
>>> I'm afraid I don't understand. Anyway - what I've listed above is
>>> what the language standard mandates.
>> AFAIU, for a given unit, there is only one pool of identifiers. So you 
>> could not have an identifier used at the same time by a non-static and a 
>> static symbol (that's exclusing the weak attribute). So it feels 
>> slightly strange to only cover the non-static symbols.
> 
> I guess I'm still not getting your point. What the above tells
> us is that static symbols may start with an underscore (but
> not followed by another one or an uppercase letter). Non-static
> symbols may not.
> 
>>>> Anyway, how about calling it cmdline_strncmp()? This would be easier to
>>>> spot misuse on review (i.e using strncmp() rather than _strncmp()).
>>>
>>> We already have cmdline_strcmp(), or else I would indeed have used
>>> this prefix. No prefix (other than the lone underscore) seemed the
>>> next best option.
>>
>> As we parse an option, how about opt_strncmp()?
> 
> I'd still like _strncmp() better here.

Why?  It doesn't tell you anything at all about what's special about the
function.  In fact, I'd say it's confusing -- the "_" doesn't normally
mean, "do something different and special", but "do the core of
something which other things might call".

I'd much prefer opt_strncmp() than _strncmp().

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel