Subject: Re: [boost] Any interest in hashing algorithms SHA and/or FNV1a?
From: Jeff Flinn (Jeffrey.Flinn_at_[hidden])
Date: 2013-11-14 15:13:05
On 11/14/2013 2:28 PM, Christopher Kormanyos wrote:
> Hi Jeff,
>> ... all the code but the call to perform_algorithm() deal with buffering,
>> which ends up being redundant with the buffering typically provided by
>> client code.
> Thank you for this astute observation. Somehow, it never dawned on
> me that the class-internal buffering can be avoided at the cost of
> slightly extended zero-buffer and padding calculations for the final
> (non-modulus-64) block.
> It looks like I owe you 64 bytes of precious microcontroller SRAM.
Hmm, where to spend them...
I haven't done inventory on block sizes of all of the hash algorithms,
but it seems to me the primary interface of the hash types should include:
- compile time block size
- a function to accumulate a block
- a function to accumulate trailing final bytes
IMO buffering should be a separate component which could be used to
implement the layered convenience functions built upon the primary
Then I can use boost math static_lcm to get a min require block size,
then my composite hash would make an integral number of calls for each
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk