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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
