Hm. This one fails the linux CI build with

cc: error: unrecognized command line option ‘-Wformat-overflow=0’
cc: error: unrecognized command line option ‘-Wformat-truncation=0’

(So, this is not ready to merge.)

The seeds are now 64 bits (uint64_t). To print them correctly, we need to use %lu on 64-bit platforms... but %llu on 32-bit platforms. Fortunately, C99 introduced a portable way to support both:

#include <inttypes.h>

    printf("Seed %" PRIu64 ":\n", theSeed);

Alternatively, an explicit cast also works on all platforms, and is already used in 3 other places:

    printf("Seed %llu:\n", (unsigned long long)theSeed);

Ah, format-overflow was introduced in GCC 7.2. The build system must be using an older version. Not sure what the best solution is: checking compiler version? a separate make target for format warnings?

Fortunately, C99 introduced a portable way to support both

Thank you, I'll incorporate that.

Not sure what the best solution is

The original motivation was to compile when CFLAGS includes -Werror=format-security, to satisfy arch linux (I believe it is that option which it sets by default?) One would hope that a work-around would be compatible with that.

Is using %llu for 64bit not correct/portable? long long is >=64

The Ubuntu 16.04 Actions environment gets deprecated in September, we could upgrade now

Is using %llu for 64bit not correct/portable? long long is >=64

Probably fine (it works on gcc and clang in practice, after all!) but if some other compiler wants to treat long long as 128 bits, I'm not sure that printf wouldn't screw something up when given %llu (128 bits) in the format string, but uint64_t (64 bits) in the parameters. I think that's why -Werror=format-security gives a warning.

Ok. Explicit casts and ubuntu 18.04 are in. My own local CI passes. I think we're mergeable, thoughts?

What do we think of using PRIu64?

What do we think of using PRIu64?

My guess is it would seem less intuitive to a future maintainer than the explicit casts. I doubt we care about any precision/sizing/overflow implications of the explicit cast either.

Hmm, I might prefer it from a type abstraction POV. At one point I was considering a seed_t type, maybe with equiv PRIseed macro - but because C, it's a useless abstraction for anything but clarity/intent, as to program correctly in all cases one must know its size and signedness. So ok, let's go with this. TY!