[RFC] A need for "yesno"-function? (and "cleanup" of kernel.h) (was: Re: [KJ] [RFC] A need for a "yesno"-function?)

[RFC] A need for "yesno"-function? (and "cleanup" of kernel.h) (was: Re: [KJ] [RFC] A need for a "yesno"-function?)

[Richard Knutsson]

Added LKML to the Cc: to see if there is someone there who also have any 
comments...

Arnaldo Carvalho de Melo wrote:
> On 3/15/07, Richard Knutsson <ricknu-0@student.ltu.se> wrote:
>> Hi
>>
>> Was just checking up the 'sparse' when I saw something like "abc"[value]
>> and thought: what about the (statement) ? "yes" : "no" I have seen in
>> the kernel.
>>
>> Ran:
>> grep -Enr "\?.*y.*\:.*n" *
>> and to my surprise, it was not so false-positive-prone and there are
>> many who does it. (Piping it to "grep yes" resulted in 153 hits) So I
>> thought, if we could standardize this and eliminate some jmp-commands
>> while doing it (the compiler should make the functions below inline), it
>> might be interesting.
>>
>> char yesno_chr(const bool value)
>> {
>>         return "ny"[value];
>> }
>>
>> char *yesno_str(const bool value)
>> {
>>         return &"no\0yes"[3 * value];
>> }
>>
>>
>> (there may be better names for them)
>> I believe this should be slightly faster. I wrote two programs (one for
>> each approach) and used 'time' while running them, and in a loop of
>> 1000,000 I found the above to be slightly faster, but the variations
>> between runs were larger.
>> So maybe it is as well to write: return value ? "yes" : "no"; but i
>> think there is a need for this kind of functions at least.
>>
>> Thoughts?
>
> The function makes sense, how you implement it? Something simple as
> this is hardly on a fast path 8)
True, but every cycled wasted... ;)
But a (condition) ? "yes" : "no" is preferable here, I guess (as it is 
more readable). The big problem is, where to put it? Seems wrong to put 
in <linux/string.h> since it appear to be a replica of userspace's 
<string.h> (otherwise, why put mem*-functions in there?).
A new file? What would it be then, "string_generic.h" maybe, and perhaps 
put in the pr_(info/debug), KERN_(WARN/...) and v?printk() (well, all 
those functions) in there. This means it will have to be included by 
<linux/kernel.h> but I think it would be a good thing to split out a few 
functions from it.

Just putting some ideas out there, any suggestions?

Richard Knutsson

Re: [RFC] A need for "yesno"-function? (and "cleanup" of kernel.h) (was: Re: [KJ] [RFC] A need for a "yesno"-function?)

[Bernd Petrovitsch]

On Fri, 2007-03-16 at 16:24 +0100, Richard Knutsson wrote:
[...]
> more readable). The big problem is, where to put it? Seems wrong to put 
> in <linux/string.h> since it appear to be a replica of userspace's 
> <string.h> (otherwise, why put mem*-functions in there?).

memcpy(3) and memcmp(3) are also there in user-space.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: [RFC] A need for "yesno"-function? (and "cleanup" of kernel.h) (was: Re: [KJ] [RFC] A need for a "yesno"-function?)

[Richard Knutsson]

Bernd Petrovitsch wrote:
> On Fri, 2007-03-16 at 16:24 +0100, Richard Knutsson wrote:
> [...]
>   
>> more readable). The big problem is, where to put it? Seems wrong to put 
>> in <linux/string.h> since it appear to be a replica of userspace's 
>> <string.h> (otherwise, why put mem*-functions in there?).
>>     
>
> memcpy(3) and memcmp(3) are also there in user-space.
>   
Did I miss something or did you just restate what was stated? (If it was 
not a replica, I think the mem*-functions would be better placed in 
memory.h, or such)

Richard Knutsson

Re: [RFC] A need for "yesno"-function? (and "cleanup" of kernel.h)

[Bernd Petrovitsch]

On Fri, 2007-03-16 at 18:09 +0100, Richard Knutsson wrote:
> Bernd Petrovitsch wrote:
> > On Fri, 2007-03-16 at 16:24 +0100, Richard Knutsson wrote:
> > [...]
> >   
> >> more readable). The big problem is, where to put it? Seems wrong to put 
> >> in <linux/string.h> since it appear to be a replica of userspace's 
> >> <string.h> (otherwise, why put mem*-functions in there?).
> >>     
> >
> > memcpy(3) and memcmp(3) are also there in user-space.
> >   
> Did I miss something or did you just restate what was stated? (If it was 
> not a replica, I think the mem*-functions would be better placed in 
> memory.h, or such)

Ah,  I misunderstood it as if you wonder why mem*() functions in
<string.h>.
Sorry.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: [RFC] A need for "yesno"-function? (and "cleanup" of kernel.h) (was: Re: [KJ] [RFC] A need for a "yesno"-function?)

[Jan Engelhardt]

On Mar 16 2007 16:24, Richard Knutsson wrote:
>> > 
>> > char yesno_chr(const bool value)
>> > {
>> >        return "ny"[value];
>> > }
>> > 
>> > char *yesno_str(const bool value)
>> > {
>> >        return &"no\0yes"[3 * value];
>> > }

static/extern const char *const yesno[] = {"no", "yes"};
static inline const char *yesno_str(bool value)
{
	return yesno[value];
}
#or
#define yesno_str(value) yesno[!!(value)]

>> > Thoughts?


Jan
-- 

Re: [RFC] A need for "yesno"-function? (and "cleanup" of kernel.h)

[Richard Knutsson]

Jan Engelhardt wrote:
> On Mar 16 2007 16:24, Richard Knutsson wrote:
>   
>>>> char yesno_chr(const bool value)
>>>> {
>>>>        return "ny"[value];
>>>> }
>>>>
>>>> char *yesno_str(const bool value)
>>>> {
>>>>        return &"no\0yes"[3 * value];
>>>> }
>>>>         
>
> static/extern const char *const yesno[] = {"no", "yes"};
> static inline const char *yesno_str(bool value)
>   
Should we use "inline"? Isn't it better to leave that to the compiler?
Why the "const"?
> {
> 	return yesno[value];
> }
>   
That's better :)
But I think a simple

static char *yesno_str(bool value)
{
	return value ? "yes" : "no";
}
is to prefer, don't you? It is simpler and we don't need to deal with an unnecessary array (unless it may be used by itself, that is. Then I would go for your implementation).

> #or
> #define yesno_str(value) yesno[!!(value)]
>   
Why not "(bool)value" instead? We cast all the other times we want a 
something to be of a different kind.

Any thoughts where to put a function like this?

Richard Knutsson