Use of htobe64 and other non-standard functions

[Anton-V-K]

The macros like htobe64 (it is used in SHA512::finalize) are written in compiler-specific way (gcc-only?), so they make it hard to build the library with other compilers.
It would be nice to rewrite them in a standard way to make the library easily portable to other platforms.

PS: I was trying to build the library with Microsoft C++ compiler (VS2017)

[rweather]

The intention was that platform-specific or compiler-specific alternatives would be provided via #ifdef's in EndianUtil.h, as it is hard to do endian conversions efficiently in standard C in a manner that is safe against side-effects.

The byteswap instrinsics in Visual C might do what you want:
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/byteswap-uint64-byteswap-ulong-byteswap-ushort?view=vs-2019

If you can get it to work, then submit a merge request and I'll add it to the library.

[Anton-V-K]

Thanks for the reply.
I'm not familiar with gcc-specific keyword __extension__ and could be overlooking something, but I'm wondering why functions like htobe64 were created as C-macros and not as inline functions?
For instance, the existing code

#define htobe32(x)  \
    (__extension__ ({ \
        uint32_t _temp = (x); \
        ((_temp >> 24) & 0x000000FF) | \
        ((_temp >>  8) & 0x0000FF00) | \
        ((_temp <<  8) & 0x00FF0000) | \
        ((_temp << 24) & 0xFF000000); \
    }))

can be easily transformed into portable inline function like:

inline uint32_t htobe32(uint32_t x)  {
        uint32_t _temp = x;
    return
        ((_temp >> 24) & 0x000000FF) |
        ((_temp >>  8) & 0x0000FF00) |
        ((_temp <<  8) & 0x00FF0000) |
        ((_temp << 24) & 0xFF000000);
}

I believe, the generated byte-code may also be efficient enough.
Is such rewrite acceptable?

[MauroMombelli]

there seems to be huge difference in the way the code is compiler, the version with extension looks like more than double long, see https://godbolt.org/z/jfzK9G