Re: bcrypt: Add a builtin sha384/sha512 implementation. (v2)

[Sebastian Lackner]

On 08.03.2017 12:17, Jacek Caban wrote:
> On 08.03.2017 12:03, Sebastian Lackner wrote:
> > +void sha512_init(SHA512_CTX *ctx)
> > +{
> > +    ctx->len = 0;
> > +    ctx->h[0] = 0x6a09e667f3bcc908;
> > +    ctx->h[1] = 0xbb67ae8584caa73b;
> > +    ctx->h[2] = 0x3c6ef372fe94f82b;
> > +    ctx->h[3] = 0xa54ff53a5f1d36f1;
> > +    ctx->h[4] = 0x510e527fade682d1;
> > +    ctx->h[5] = 0x9b05688c2b3e6c1f;
> > +    ctx->h[6] = 0x1f83d9abfb41bd6b;
> > +    ctx->h[7] = 0x5be0cd19137e2179;
>
> I think those are still not portable, because those constants are too
> large. You may use something like ((ULONG64)0x6a09e667<<32)|0xf3bcc908.
>
> Jacek

I was wondering about that too, but it looks like we have already
various places where 64-bit consts are used without any ugly tricks.
Examples are in tests, include files, and also implementation code.
Is it really necessary? Or is it only the suffix which causes trouble?

Best regards,
Sebastian

bcrypt: Add a builtin sha384/sha512 implementation. (v2)

[Simon Richter]

Hi,

On 08.03.2017 12:29, Sebastian Lackner wrote:
> I was wondering about that too, but it looks like we have already
> various places where 64-bit consts are used without any ugly tricks.

I think that is a gcc extension. MSVC tells me off for using 64 bit
literals without a suffix, and cuts off the upper bits.
> Examples are in tests, include files, and also implementation code.
> Is it really necessary? Or is it only the suffix which causes trouble?

Out of curiosity, what is the problem with the suffix?

   Simon