In drivers/char/sysrq.c (2.4 and 2.5) we have :
if ((key >= '0') & (key <= '9')) {
retval = key - '0';
} else if ((key >= 'a') & (key <= 'z')) {
Shouldn't the "&" be (pedantically) "&&" ?
Margit
On Fri, 30 May 2003 16:44:55 +0200, Margit Schubert-While wrote:
>
> In drivers/char/sysrq.c (2.4 and 2.5) we have :
>
> if ((key >= '0') & (key <= '9')) {
> retval = key - '0';
> } else if ((key >= 'a') & (key <= 'z')) {
>
> Shouldn't the "&" be (pedantically) "&&" ?
It is semantically the same. If you can show that gcc optimization
also creates the same assembler code, few people will object to a
patch.
J?rn
--
Measure. Don't tune for speed until you've measured, and even then
don't unless one part of the code overwhelms the rest.
-- Rob Pike
On 05.30, J?rn Engel wrote:
> On Fri, 30 May 2003 16:44:55 +0200, Margit Schubert-While wrote:
> >
> > In drivers/char/sysrq.c (2.4 and 2.5) we have :
> >
> > if ((key >= '0') & (key <= '9')) {
> > retval = key - '0';
> > } else if ((key >= 'a') & (key <= 'z')) {
> >
> > Shouldn't the "&" be (pedantically) "&&" ?
>
> It is semantically the same. If you can show that gcc optimization
> also creates the same assembler code, few people will object to a
> patch.
>
I see a diff:
- & is bitwise and you always perform the op
- && is logical and gcc must shortcut it
I think people use & 'cause they prefer the extra argument calculation
than the branch for the shortcut (AFAIR...)
or not ?
--
J.A. Magallon <[email protected]> \ Software is like sex:
werewolf.able.es \ It's better when it's free
Mandrake Linux release 9.2 (Cooker) for i586
Linux 2.4.21-rc6-jam1 (gcc 3.2.3 (Mandrake Linux 9.2 3.2.3-1mdk))
On Fri, 30 May 2003 17:13:17 +0200, J.A. Magallon wrote:
> On 05.30, J?rn Engel wrote:
> > On Fri, 30 May 2003 16:44:55 +0200, Margit Schubert-While wrote:
> > >
> > > In drivers/char/sysrq.c (2.4 and 2.5) we have :
> > >
> > > if ((key >= '0') & (key <= '9')) {
> > > retval = key - '0';
> > > } else if ((key >= 'a') & (key <= 'z')) {
> > >
> > > Shouldn't the "&" be (pedantically) "&&" ?
> >
> > It is semantically the same. If you can show that gcc optimization
> > also creates the same assembler code, few people will object to a
> > patch.
> >
>
> I see a diff:
> - & is bitwise and you always perform the op
> - && is logical and gcc must shortcut it
>
> I think people use & 'cause they prefer the extra argument calculation
> than the branch for the shortcut (AFAIR...)
Yes, it is an optimization, nothing more. Either code will behave the
same, but one version might be a little faster, depending on the cpu,
unless the compiler is already clever enough to do this himself.
Just wrote a small test program with both variants and tested on i386
with gcc 3.2.3 and 2.95.4, with -O2 and -Os. The code generated was
identical in all eight cases. So if ever this zero optimization
reduces readability of the code, write a patch and make it better.
Beats any spelling fixes.
J?rn
--
Eighty percent of success is showing up.
-- Woody Allen