Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> + set_uint32 (r + 0 * sizeof ctx->A, SWAP (ctx->A));
>> + set_uint32 (r + 1 * sizeof ctx->B, SWAP (ctx->B));
>> + set_uint32 (r + 2 * sizeof ctx->C, SWAP (ctx->C));
>> + set_uint32 (r + 3 * sizeof ctx->D, SWAP (ctx->D));
>
> Now
Jim Meyering wrote:
> + set_uint32 (r + 0 * sizeof ctx->A, SWAP (ctx->A));
> + set_uint32 (r + 1 * sizeof ctx->B, SWAP (ctx->B));
> + set_uint32 (r + 2 * sizeof ctx->C, SWAP (ctx->C));
> + set_uint32 (r + 3 * sizeof ctx->D, SWAP (ctx->D));
Now this is confusing. If you assume that A, B, C, D a
Jim Meyering <[EMAIL PROTECTED]> writes:
> While making similar changes to sha256.c and especially sha512.c
> (where the 4 would become 8) in coreutils, I found changes like
> these to be essential:
>
> Use "sizeof VAR", rather than a literal "4".
> * lib/md5.c (md5_read_ctx): Use size
FYI, I've just pushed this:
Remove alignment constraint from the sha*_read_ctx functions.
* lib/sha256.c (set_uint32): New function.
(sha256_read_ctx, sha224_read_ctx): Use it.
* lib/sha512.c (set_uint64): New function.
(sha512_read_ctx, sha384_read_ctx): Us
While making similar changes to sha256.c and especially sha512.c
(where the 4 would become 8) in coreutils, I found changes like
these to be essential:
Use "sizeof VAR", rather than a literal "4".
* lib/md5.c (md5_read_ctx): Use sizeof ctx->A, not 4.
* lib/md4.c (md4_read_c
Jim Meyering <[EMAIL PROTECTED]> writes:
>> * lib/sha1.h (SHA1_DIGEST_SIZE): Add.
>
> Good idea. You're welcome to commit that.
>
> s/Add/Define/
...
>> Jim,
>>
>> How about this self-test module for sha1?
>
> Good idea.
> Thanks for adding that.
Pushed.
Thanks,
Simon
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> Jim,
>
> How about this self-test module for sha1?
>
> /Simon
> Files:
> tests/test-sha1.c
Good idea.
Thanks for adding that.
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> Jim, I noticed that sha1.h is missing a SHA1_DIGEST_SIZE #define, which
> can be useful in code using the sha1 package (such as the self test in
> the previous post..). md2, md4 and md5 have similar defines. What do
> you think about adding it to sha1.
Jim,
How about this self-test module for sha1?
/Simon
Files:
tests/test-sha1.c
Depends-on:
configure.ac:
Makefile.am:
TESTS += test-sha1
check_PROGRAMS += test-sha1
/*
* Copyright (C) 2005, 2008 Free Software Foundation
* Written by Simon Josefsson
*
* This program is free software: you ca
Jim, I noticed that sha1.h is missing a SHA1_DIGEST_SIZE #define, which
can be useful in code using the sha1 package (such as the self test in
the previous post..). md2, md4 and md5 have similar defines. What do
you think about adding it to sha1.h? I.e.:
2008-01-31 Simon Josefsson <[EMAIL PRO
Jim Meyering <[EMAIL PROTECTED]> wrote:
> I've just pushed the change adding this new module.
> As far as I know, it's used only via the Makefile.maint-style
> rules that are run as part of e.g., coreutils "make syntax-check".
FYI, there's another use: coreutils' "make check" also uses
it in test
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon,
>
>> I have pushed changes for md2, md4 and md5.
>
> Here's an additional proposed refinement. With it, gcc generates much better
> code (on x86: a single instruction instead of a function call of a function
> with 5 instructions).
The code seems
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> Here's another refinement.
>> Simon, since you're listed as md4 owner, I'll wait for your ok...
>
> Fine with me!
Good :) Pushed.
Jim Meyering <[EMAIL PROTECTED]> writes:
> Here's another refinement.
> Simon, since you're listed as md4 owner, I'll wait for your ok...
Fine with me!
Thanks,
Simon
Here's another refinement.
Simon, since you're listed as md4 owner, I'll wait for your ok...
>From 583a8ea5a0e5b56f46a5b423ca736b83ea2a0742 Mon Sep 17 00:00:00 2001
From: Jim Meyering <[EMAIL PROTECTED]>
Date: Thu, 31 Jan 2008 13:04:07 +0100
Subject: [PATCH] Prefer "sizeof v" over the equivalent "
Bruno Haible <[EMAIL PROTECTED]> wrote:
>> I have pushed changes for md2, md4 and md5.
>
> Here's an additional proposed refinement. With it, gcc generates much better
> code (on x86: a single instruction instead of a function call of a function
> with 5 instructions).
>
> 2008-01-31 Bruno Haible
Simon,
> I have pushed changes for md2, md4 and md5.
Here's an additional proposed refinement. With it, gcc generates much better
code (on x86: a single instruction instead of a function call of a function
with 5 instructions).
2008-01-31 Bruno Haible <[EMAIL PROTECTED]>
* lib/md4.c
I've just pushed the change adding this new module.
As far as I know, it's used only via the Makefile.maint-style
rules that are run as part of e.g., coreutils "make syntax-check".
Changes from the version in coreutils:
I've just reintroduced support for mercurial (only lightly tested),
and rearra
Jim Meyering <[EMAIL PROTECTED]> writes:
> Bruno Haible <[EMAIL PROTECTED]> wrote:
>
>> Jim Meyering wrote:
>>> Thanks for the suggestion. It looks like a good one.
>>
>> The suggestion also applies to the 'md5' module, after which the 'sha1'
>> module
>> is modeled.
>
> Yep. md2 and md4 too.
>
Jim Meyering <[EMAIL PROTECTED]> writes:
> Bruno Haible <[EMAIL PROTECTED]> wrote:
>
>> Jim Meyering wrote:
>>> Thanks for the suggestion. It looks like a good one.
>>
>> The suggestion also applies to the 'md5' module, after which the 'sha1'
>> module
>> is modeled.
>
> Yep. md2 and md4 too.
>
Jim Meyering <[EMAIL PROTECTED]> wrote:
> David Shaw <[EMAIL PROTECTED]> wrote:
>> Peter Palfrader reported a bug against the sha1 code in paperkey, but
>> that code actually comes from gnulib, so I'm referring it to you.
>>
>> The issue comes up (as noted in the comment) if resbuf is not 32-bit
>>
Bruno Haible <[EMAIL PROTECTED]> writes:
> Jim Meyering wrote:
>> Thanks for the suggestion. It looks like a good one.
>
> The suggestion also applies to the 'md5' module, after which the 'sha1' module
> is modeled.
>
> But if you apply the suggestion to both the sha1 and md5 modules, we get
> an
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> Thanks for the suggestion. It looks like a good one.
>
> The suggestion also applies to the 'md5' module, after which the 'sha1' module
> is modeled.
Yep. md2 and md4 too.
For now, I've pushed the sha1 changes.
> But if you apply
23 matches
Mail list logo
