sha1 hash using libgcrypt different from what returns sha1sum

[Rafaël Carré]

Hello,

Werner Koch <wk at gnupg.org> a écrit :
>On Fri, 13 Dec 2013 21:51, jussi.kivilinna at iki.fi said:
>
>> That's right, size_t for lengths is not enough on 32-bit. Could we
>use uint64_t
>> instead of size_t?
>
>uint64_t is not really portable because C99 is not deployed everywhere.

Are you thinking about Visual Studio and its incomplete C99 support?

I hope that's the only compiler left that doesn't support C99. And I'm not sure you should keep gcrypt off of 15 years old features just because of it.

If there're others compilers I'd like to know because I've been using C99 extensively for a few years.

In any case we've had these types in mingw for a while and I think there are copies of a MSVC compatible stdint.h in the wild.

>However, this is a minor issue because we could enable CCM only if we
>have that type.  We do the same for some algorithm (TIGER comes to
>mind).
>
>We could document a certain limit on CCM or we look for a more general
>solution.  In Windows this has traditionally be solved using unions and
>structs.  It's not nice API, though.
>
>off_t would be a natural choice but it has problems as well.  For
>example the two defined ABI variants and I have not checked whether it
>is suitable for a size_t replacement (I guess not).

I think off_t depends on __USE_FILE_OFFSET64 at least on 32 bits so it doesn't sound like a good choice.

>What do we we need to change in the API to correctly support it.  What
>side-effects will be have if we use uint64_t and provide the interfaces
>only if uint64 is defined?

Applications failing to link correctly when built with the non C99 able compilers I guess, I can't think of something else.

>Shalom-Salam,
>
>   Werner

Regards,