Thread: Re: 64 bit numbers vs format strings

On Thu, Dec 5, 2024 at 5:12 PM Thomas Munro <thomas.munro@gmail.com> wrote:
>
> Having learned some things about gettext based on clues[1] from Peter
> E, I decided to see what it would take to expunge all (long long) and
> similar casts now that we're using the standard types with system
> support.
>
> The short version is tha given uint64 x:
>
>     Old: errmsg("hello %llu", (unsigned long long) x)
>     New: errmsg("hello %" PRIu64, x)
>
> (And all other printf-like interfaces).  That d can be x, X, u, etc
> and you can put the usual stuff between % and the macro, so it's cut
> up slightly differently than our own macros for that stuff.

Yay!

I didn't look at the pgbench bits and don't know the answer to any of
the questions you asked in your mail (re difficulty introduced when
backporting etc), but big +1 from me on doing this.

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’}

- Melanie

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...