Re: possible bug in sha and crc32 digest classes

[Elizabeth Barham]

> template <class int_type>
> std::ostream & SHATumbler<int_type>::toString(std::ostream & os)
> {
>       unsigned i;
>       unsigned long h1, h2;

This should *probably* be:

        int_type h1, h2;

>       for(i = 0 ; i < (unsigned)size ; i++) {
>               
> #ifdef DEBUG_SHATUMBLER
>               if(i != 0)
>                       os << " ";
> #endif

This appears to be an effort to split the "tumbler" (a uint32_t and
possibly a uint64_t in the future) into a HIGH part and LOW part.

> #if defined(WIN32) && !defined(__MINGW32__)
>               h1 = h[i] / 0x10000;
>               h2 = h[i] % 0x10000;
> #else
>               h1 = h[i] / 0x10000LL;
>               h2 = h[i] % 0x10000LL;
> #endif

The above may not work as expected if we modify "unsigned long" to
"int_type" since there is no guarantee on the length of "int_type".

Perhaps something akin to:

                h1 = h[i] / (1 << (sizeof(h[i]) / 2);
                h2 ...

would work better?

> 
>               os << std::hex << std::setw(sizeof(h1) * 2) << 
>                       std::setfill('0') << h1;
> 
>               os << std::hex << std::setw(sizeof(h2) * 2) << 
>                       std::setfill('0') << h2;

and since the tumbler has been split into two halves with the output
in the lower halves, there is no need to have the "* 2" (the sizeof
will return the correct number of characters that will need to be used
to represent one half of the datum).

>       }
>       return(os);
> }

Out of curiosity, what prompted the modification to use h1 and h2?

Sincerely,
Elizabeth