Re: 64 bit numbers vs format strings

On Fri, Dec 6, 2024 at 1:15 PM Melanie Plageman
<melanieplageman@gmail.com> wrote:
> So, will this fix the issue that when I do:
>
> uint64 somevar = 0;
> errmsg("hello %lu", somevar)
>
> locally on my x86-64 linux machine running ubuntu with whatever gcc-11
> comes out of the box, it compiles sans warnings, but in the
> mingw_cross_warning task in CI, it warns with:
>
> error: format ‘%lu’ expects argument of type ‘long unsigned int’, but
> argument 2 has type ‘uint64’ {aka ‘long long unsigned int’}

Yes, just never use %l or %ll again for fixed width types.

My experience while hacking that up and pushing it through CI quite a
few times was that only off_t remains painful like that.  The
CompileWarnings' mingw_cross_warning test blows up if you use PRId64
and then feed it an off_t, without casting it to (pgoff_t), because it
has sizeof(offt_t) == 4.  It may be the only defence we have because:

* The CI Visual Studio build also has sizeof(off_t) == 4 but we
haven't decorated our printf stuff with whatever it needs to check
them so it doesn't care (if it even can, IDK).
* The BF animals testing Visual Studio are the same.
* The CI MinGW build that probably few ever run has sizeof(off_t) ==
8, because it's using meson and it sets -D_FIILE_OFFSET_BITS=64 and
that makes it do that, unlike mingw_cross_warning which is using
configure.
* The BF animal fairywren is the same (you can't tell from the
outside, meson doesn't define or print SIZEOF_OFF_T, maybe it should
to make things less mysterious).

Perhaps there is a clever way to "poison" off_t so that it is
incompatible with int64_t.  For example, if it's 64 bit and if we can
figure out that int64_t is really long under the covers, make it long
long, and vice versa, so that you get a warning.  But that's a bit
weird and might have other problems.  Printing off_t is not too common
though so maybe mingw_cross_warning is enough...