Use fixed-width types instead of built-in types

[mikomikotaishi]

Could we instead of using types like unsigned long long and unsigned char, use fixed-width types (such as uint64_t and uint8_t respectively)?

I encountered this when trying to use the library:

/usr/include/sodium/crypto_sign.h:73:5: note: candidate function not viable: no known conversion from 'u64 *' (aka 'unsigned long *') to 'unsigned long long *' for 2nd argument
   73 | int crypto_sign_detached(unsigned char *sig, unsigned long long *siglen_p,

Of course, I have using u64 = std::uint64_t;, and I do not think the intended size in these parameters is 128 bits.

[jedisct1]

I wish we didn't use unsigned long long for sizes, but that's the original NaCl API, and the standard SUPERCOP interface.

That cannot be changed any more, as It would break all existing applications.

[mikomikotaishi]

That's frustrating, it looks like OpenSSL seems to have the same inertia as well (using int, unsigned char, etc.)

If this problem was ever brought up to you before (I haven't seen it been raised in an issue or discussion page), do you have any suggestions on what to to overcome this problem? Should I just cast, or use unsigned long long in my code?

Also, I am not asking to insist on making the change, but rather for my own understanding: why would changing unsigned long long to uint64_t be a breaking change? unsigned long long is, to my understanding, guaranteed to be at least 64 bits, but I do not think it is in practice ever greater than 64.

Would it be possible if we did something like

// most normal platforms where unsigned long long is 64 bits
#if ULL_IS_NORMAL
typedef uint64_t UnsignedLongLong
#else
typedef unsigned long long UnsignedLongLong
#endif

I don't know if this would work, it's just an idea I'm throwing out and wondering if it may work.

[jedisct1]

Fixed sizes like uint64_t don't really make sense for sizes, as they depend on the pointer width. On a 32-bit system, uint64_t would be misleading.

size_t is what would make sense for something representing an object in memory. Unless this is mapped memory, where something like off_t would make more sense.

They will both implicitly upcast to unsigned long long, so you generally don't have to worry about it.

Lengths returned by address use unsigned long long for consistency. But these lengths are never larger than input lengths. So if you use size_t for input lengths, you can safely downcast the unsigned long long returned size to size_t.

[mikomikotaishi]

Would the hypothetical approach of using a typedef depending on whether the system defines unsigned long long as exactly 64 bits, and if so chooses uint64_t and otherwise choosing unsigned long long (such as if uint64_t does not exist/the system is 32-bit, or the exotic case where unsigned long long is not 64 bits, i.e. it is 128 bits) be appropriate at all to overcome this?

Also, what about switching unsigned char for uint8_t? I don't know of any notable systems where the two are not the same.

Again, only asking about hypotheticals and limitations, not trying to insist on the change.