[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On 09.12.2019 15:06, George Dunlap wrote:
> 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().

Noted - will do.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.