[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <818B7FCF-3713-42E8-8EFF-2ECC98217BEE@mac.com>
Date: Sat, 23 Sep 2006 16:42:47 -0400
From: Kyle Moffett <mrmacman_g4@....com>
To: Kyle Moffett <mrmacman_g4@....com>
Cc: Herbert Xu <herbert@...dor.apana.org.au>,
David Miller <davem@...emloft.net>,
linux-kernel@...r.kernel.org, torvalds@...l.org
Subject: Re: [PATCH]: Fix ALIGN() macro
On Sep 23, 2006, at 16:36:33, Kyle Moffett wrote:
> On Sep 23, 2006, at 10:40:41, Herbert Xu wrote:
>> diff --git a/crypto/hmac.c b/crypto/hmac.c
>> index f403b69..d52b234 100644
>> --- a/crypto/hmac.c
>> +++ b/crypto/hmac.c
>> @@ -98,7 +98,7 @@ static int hmac_init(struct hash_desc *p
>> sg_set_buf(&tmp, ipad, bs);
>>
>> return unlikely(crypto_hash_init(&desc)) ?:
>> - crypto_hash_update(&desc, &tmp, 1);
>> + crypto_hash_update(&desc, &tmp, bs);
>> }
>>
>> static int hmac_update(struct hash_desc *pdesc,
>
> Quick question: does "crypto_hash_init()" ever return anything
> other than 0 or 1? If so this is a subtle bug, as "unlikely()" is
> implemented like this:
>
> # define unlikely(x) __builtin_expect(!!(x), 0)
>
> IMO any usage of likely/unlikely other than if(unlikely()), if
> (likely()) is probably a bug.
With a bit more contemplation, I think this is one place where (if
the compiler or sparse are cooperative) we should really look at the
_Bool type or similar. If we could cast likely()/unlikely() to
return (_Bool), then these sorts of problems would be caught at
compile time, and likewise for other functions which return boolean
values.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists