Hi Paul, > > Out of personal interest, do you happen to know what platforms Emacs > > builds on that lack 64-bit types? > > Emacs is a bit of a special case as it builds on verrry ooold platforms, > including platforms no longer supported by their suppliers, and we're > reasonably reluctant to require uint64_t except in platform-specific > code where we know it's available. For example, there have been fairly > recent (circa 2023) additions to Emacs working around the lack of > uint64_t on older Android in certain compilation environments. For an > example of these old environment's hassles (having to do with c89 vs c99 > compatibility, ouch), see > <https://cs.android.com/android/_/android/platform/bionic/+/6d6731adc0cd0fb249a2b73a575e5ab2204643cc> > > which indicates this was an issue through at least Android Jelly Bean > (2012), and I think the problem was even worse in earlier Android versions.
But Android of 2012 uses gcc as compiler, and gcc supports 'long long' and 'unsigned long long' on these platforms (arm, arm64, x86). So, instead of using the 'u64' module in order to avoid uint64_t, it would be much simpler to make <stdint.h> define the missing int64_t and uint64_t types. If Gnulib's current <stdint.h> override does not do this, it should be simple to add. > For what it's worth, in theory one must be careful with all the uint*_t > types, as the standards say that integer overflow can have undefined > behavior with any of them (because in theory they could all fit in > 'int'). I read the standard differently: ISO C 23 § 7.22.1.1.(2) "The typedef name uintN_t designates an unsigned integer type with width N and no padding bits." ISO C 23 § 6.2.5.(11) "A computation involving unsigned operands can never produce an overflow, because arithmetic for the unsigned type is performed modulo 2^N ." So, uintN_t arithmetic is overflow-free, just like 'unsigned int' arithmetic. Bruno
