ULL constants are not C89 #745

1. 
   real-or-random commented at 5:23 pm on April 20, 2020: contributor

   The README states as a goal: “Intended to be portable to any system with a C89 compiler and uint64_t support.”

   The C89 syntax does not specify unsigned long long (ULL) constants because there is no requirement that a unsigned long long type exists. We use ULL in a few places, e.g.: https://github.com/bitcoin-core/secp256k1/blob/39198a03eaa33d5902b16d3aefa7c441232f60fb/src/scalar_4x64_impl.h#L11

   We should replace ULL with the UINT64_C macro from in stdint.h. Note that UL is not an issue: It’s in the C89 syntax and unsigned long is guaranteed to have at least 32 value bits, so we can use it for uint32_t constants. We may still want to change it for consistency and readability (clearer expression of intent).

   Alternatively, we can do nothing (because noone seemed to care about this so far).

2. real-or-random referenced this in commit cdbd5638ff on Apr 22, 2020
3. 
   prusnak commented at 3:21 pm on January 19, 2021: none

   long long is specified in C99, so possible fix would be just to replace C89 with C99 in the readme
4. 
   hebasto commented at 12:09 pm on August 12, 2025: member

   We should replace ULL with the UINT64_C macro from in stdint.h.

   If I understand this article correctly, stdint.h has been available only since C99.

5. 
   real-or-random commented at 3:32 pm on August 12, 2025: contributor

   We should replace ULL with the UINT64_C macro from in stdint.h.

   If I understand this article correctly, stdint.h has been available only since C99.

   That’s not entirely true. stdint.h is only required since C90, but it can still be present on C89. This sounds pedantic (and I admit that this issue is pretty pedantic), but the presence of additional headers is not just theoretical. The GCC docs say: “<stdint.h> is provided by GCC (as of version 4.5), or fixed where the system headers provide a nonconforming version, on some but not yet all systems.”, see https://gcc.gnu.org/projects/c-status.html#c99 .

   So the reason why the README mentions C89 is that C89 + stdint.h suffices. You don’t need “full” C99… Does this matter in 2025? Probably not. Have we ever seen a compiler that does not support ULL? No.

   I still think that something like #746 is useful, if only for the reason that UINT64_C(0xaa..aa) is simply the right thing to do if you want to specify a uint64_t. It’s more portable, and it saves the reader the cognitive overhead of figuring out how 0xaa..aaULL is converted to uint64_t. But none of this is high priority.

6. real-or-random added the label tweak/refactor on Aug 12, 2025

Contributors
real-or-random prusnak hebasto

Labels
tweak/refactor