From: Nicolas Pitre <nico@cam.org>
To: Andrew Morton <akpm@osdl.org>, Herbert Xu <herbert@gondor.apana.org.au>
Cc: lkml <linux-kernel@vger.kernel.org>
Subject: [PATCH 3/5] crypto/sha1.c: move related code together
Date: Mon, 24 Oct 2005 13:57:52 -0400 (EDT) [thread overview]
Message-ID: <Pine.LNX.4.64.0510241357110.5288@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.64.0510241347081.5288@localhost.localdomain>
The final length buffer construction in sha1_final() is moved just before
where it is used. This makes for slightly more readable code and actually
more efficient as well since the compiler doesn't have to bother preserving
the bits array across the first call to sha1_update(). In fact it makes for
slightly smaller stack usage on i386 or slightly smaller code size on ARM
(depending on your GCC version that could vary of course).
Signed-off-by: Nicolas Pitre <nico@cam.org>
Index: linux-2.6/crypto/sha1.c
===================================================================
--- linux-2.6.orig/crypto/sha1.c
+++ linux-2.6/crypto/sha1.c
@@ -76,11 +76,17 @@
{
struct sha1_ctx *sctx = ctx;
u32 i, j, index, padlen;
- u64 t;
- u8 bits[8] = { 0, };
+ u64 t, count = sctx->count;
+ u8 bits[8];
static const u8 padding[64] = { 0x80, };
- t = sctx->count << 3;
+ /* Pad out to 56 mod 64 */
+ index = count & 0x3f;
+ padlen = (index < 56) ? (56 - index) : ((64+56) - index);
+ sha1_update(sctx, padding, padlen);
+
+ /* Append length */
+ t = count << 3;
bits[7] = 0xff & t; t>>=8;
bits[6] = 0xff & t; t>>=8;
bits[5] = 0xff & t; t>>=8;
@@ -89,13 +95,6 @@
bits[2] = 0xff & t; t>>=8;
bits[1] = 0xff & t; t>>=8;
bits[0] = 0xff & t;
-
- /* Pad out to 56 mod 64 */
- index = sctx->count & 0x3f;
- padlen = (index < 56) ? (56 - index) : ((64+56) - index);
- sha1_update(sctx, padding, padlen);
-
- /* Append length */
sha1_update(sctx, bits, sizeof bits);
/* Store state in digest */
next prev parent reply other threads:[~2005-10-24 17:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-24 17:54 [PATCH 0/5] crypto/sha1.c: code cleanup Nicolas Pitre
2005-10-24 17:56 ` [PATCH 1/5] crypto/sha1.c: avoid useless memcpy() Nicolas Pitre
2005-10-24 17:57 ` [PATCH 2/5] crypto/sha1.c: avoid shifting count left and right Nicolas Pitre
2005-11-13 0:29 ` Herbert Xu
2005-10-24 17:57 ` Nicolas Pitre [this message]
2005-10-24 18:03 ` Nicolas Pitre
2005-10-24 18:03 ` [PATCH 5/5] crypto/sha1.c: final cleanup Nicolas Pitre
2005-10-24 18:05 ` [PATCH 4/5] crypto/sha1.c: avoid successively shifting a long long Nicolas Pitre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.0510241357110.5288@localhost.localdomain \
--to=nico@cam.org \
--cc=akpm@osdl.org \
--cc=herbert@gondor.apana.org.au \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®