std.hash: More questions

[Johannes Pfau]

Am Fri, 06 Jul 2012 01:24:04 +0400
schrieb Dmitry Olshansky <dmitry.olsh at gmail.com>:

> 
> The only thing  I can think of that would require start function is 
> using unconventional initial vectors.
> 

Those could be done as template parameters though? (If the hash is
written as a templated struct).

But e.g. OpenSSL has *_init functions as well, so we probably should
keep the start function even if it's just to allow wrappers for
OpenSSL?

> >
> > CRC32 sums are usually presented as a uint, not a ubyte[4]. To fit
> > the rest of the API ubyte[4] is used. Now there's a small annoying
> > detail: The CRC32 should be printed in LSB-first order.
> You probably meant MSB first.

The rosettacode.org site which I used to verify the CRC32 results said
LSB-first but it seems it only describes the data layout of the uint
value (Little Endian). The printf/writef result is indeed MSB-first.

> 
> > When printing an uint like this, that works well:
> > writefln("%#x", 4157704578); //0xf7d18982
> > but this doesn't:
> > toHexString(*cast(ubyte[4]*)&4157704578); //8289D1F7
> 
> There is no problem it's just order of printing that at fault. So I 
> suggest to *stop* doing a bswap.
> 
> It's just that printing something as an array of ubytes does it from 
> least significant byte to most significant. You could try to add 
> MSB/LSB first options to toHexString.

Yes, but that's not very intuitive. Most people would expect the same
result (by default) that other languages provide:
http://rosettacode.org/wiki/CRC-32

I'll add the order option to toHexString but I think I'll also
add an alias crcToHexString/crcHexString or something like that.

> 
> >
> > I can't change toHexString as it's used for all hashes and it's
> > correct for SHA1, MD5, ...
> > So I currently use bswap in the CRC32 finish() implementation to fix
> > this issue.
> >
> no-no-no see the above ;)
> 
> > Now the question is should I provide an additional finishUint
> > function which avoids the bswap?
> >
> >
> > Implementation issue:
> >
> > The current implementation of SHA1 and MD5 uses memcpy which doesn't
> > work in CTFE IIRC and which also prevents the code from being pure.
> > I could replace those memcpy calls with array copying but I'm not
> > sure if memcpy was used for performance, so I'd like to keep it as
> > long as we have no performance tests.
> >
> Replace memcpy with and array ops:
> ptr1[x..y] = ptr2[x2..y2];
> note that it's better to have them be pointers as it avoid bounds
> check & D runtime magic.
> 
> If need be I can provide benchmarks but I'm certain from the days of 
> optimizing std.regex that it's faster or on par with memcpy.
> 

OK great, pure is working. CTFE not yet, but that can be added later.

Do we want to add 'pure' as part of the functions in the Digest
interface? This would require all implementations to be pure, I don't
know if that's a good idea right now.