Re: [RFC] A need for "yesno"-function? (and "cleanup" of kernel.h)
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] A need for "yesno"-function? (and "cleanup" of kernel.h) (was: Re: [KJ] [RFC] A need for a "yesno"-function?)
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
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] A need for "yesno"-function? (and "cleanup" of kernel.h) (was: Re: [KJ] [RFC] A need for a "yesno"-function?)
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 since it appear to be a replica of userspace's (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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] A need for "yesno"-function? (and "cleanup" of kernel.h)
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 since it appear to be a replica of userspace's > >> (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 . Sorry. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] A need for "yesno"-function? (and "cleanup" of kernel.h) (was: Re: [KJ] [RFC] A need for a "yesno"-function?)
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 since it appear to be a replica of userspace's > (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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] A need for "yesno"-function? (and "cleanup" of kernel.h) (was: Re: [KJ] [RFC] A need for a "yesno"-function?)
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 <[EMAIL PROTECTED]> 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 since it appear to be a replica of userspace's
(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
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC] A need for yesno-function? (and cleanup of kernel.h) (was: Re: [KJ] [RFC] A need for a yesno-function?)
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 [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] A need for yesno-function? (and cleanup of kernel.h) (was: Re: [KJ] [RFC] A need for a yesno-function?)
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] A need for yesno-function? (and cleanup of kernel.h)
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] A need for yesno-function? (and cleanup of kernel.h) (was: Re: [KJ] [RFC] A need for a yesno-function?)
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] A need for yesno-function? (and cleanup of kernel.h) (was: Re: [KJ] [RFC] A need for a yesno-function?)
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
--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] A need for yesno-function? (and cleanup of kernel.h)
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
