Seems like Nettle.HashState (corresponding to your CRCState) inherits
Nettle.HashInfo (corresponding to CRC), not the other way around.
That can work, although I don't think it's a particularly good idea,
precisely because it tends to cause the kind of confusion you're
experiencing.
If your static algorithm data is small then you can of course put all
of it in the HashState class rather than in the HashInfo (aka
Crypto.Hash). That's your implementation freedom. Anyway, a
Crypto.Hash must work as a factory and return new unique instances.
I think Crypto.Hash and its descendants preferably shouldn't provide
actual hashing services, since that invites users to make the mistake
of actually using them, and thereby open up their code for thread
concurrency bugs.
As a point in case regarding the confusion here, I note the
Nettle.HashInfo.hash() function:
/*! @decl string hash(string data)
*!
*! Works as a (faster) shortcut for
*! @expr{obj->update(data)->digest()@}.
*!
*! @seealso
*! @[HashState()->update()] and @[HashState()->digest()].
*/
Given this definition, and assuming "obj" there refers to
this_object(), it shouldn't be in the HashInfo since it's not thread
safe. The C implementation in Nettle/hash.cmod is also thread unsafe
in practice since it does its work in a THREADS_ALLOW. I've fixed that
now, at least.
