On Wed, Nov 13, 2013 at 7:26 PM, Jeff Flinn
On 11/13/13 6:03 PM, Christopher Kormanyos wrote: ...
There is another interface detail that can lead to a useful flexibility. In addition to init --- digest --- finalize scheme, some use cases need to finalize a running hash, yet retain its state. This can be accomplished with a kind of function such as "get_result_and_nochange_the_state". In this way, a running hash final result can be obtained, but more bytes can be fed into the hash. This can be a constant member function, as a copy of the hash object needs to be made.
I've this exact situation - currently two hashes are maintained.
So what if the hash classes were written such that this were the default behavior? Specifically that finalize copies the message block state, returns the final digest to the user, and leaves the engine ready to continue processing the message digest. We can still clear the message block state in the destructor, leaving the postconditions of the class the same at the end of its lifetime. For most use cases things would be no different for the user, but there would be much greater flexibility of use without adding more APIs. - foster