git: 5b8f07b12f84 - main - Fix -Wformat errors in pfctl on 32-bit architectures

[Konstantin Belousov]

On Tue, Aug 31, 2021 at 09:54:32AM +0200, Kristof Provost wrote:
> On 31 Aug 2021, at 1:33, Konstantin Belousov wrote:
> > On Sun, Aug 29, 2021 at 07:40:09PM +0200, Dimitry Andric wrote:
> >> On 29 Aug 2021, at 18:00, Kristof Provost <kp at freebsd.org> wrote:
> >>>
> >>> On 29 Aug 2021, at 17:31, Dimitry Andric wrote:
> >>>> The branch main has been updated by dim:
> >>>>
> >>>> URL: https://cgit.FreeBSD.org/src/commit/?id=5b8f07b12f8477f1679013d6b3abdab8d33c7243
> >>>>
> >>>> commit 5b8f07b12f8477f1679013d6b3abdab8d33c7243
> >>>> Author:     Dimitry Andric <dim at FreeBSD.org>
> >>>> AuthorDate: 2021-08-29 15:31:28 +0000
> >>>> Commit:     Dimitry Andric <dim at FreeBSD.org>
> >>>> CommitDate: 2021-08-29 15:31:28 +0000
> >>>>
> >>>>    Fix -Wformat errors in pfctl on 32-bit architectures
> >>>>
> >>>>    Use PRIu64 to printf(3) uint64_t quantities, otherwise this will result
> >>>>    in "error: format specifies type 'unsigned long' but the argument has
> >>>>    type 'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat]" on 32-bit
> >>>>    architectures.
> >>>>
> >>>>    Fixes:          80078d9d38fd
> >>>>    MFC after:      1 week
> >>>
> >>> Thanks!
> >>>
> >>> I was running test builds for a fix, but it is so much more convenient when other people fix my mistakes for me.
> >>
> >> I was trying buildworld on i386 for something totally unrelated, and ran
> >> into these -Wformat errors so I took the liberty of patching them up
> >> quickly. :)
> >
> > Generally we do not use the PRIu64 (you should remember the term
> > abomination).  Why not cast to uintmax_t and use %ju as we typically do
> > in other places.
> >
> There are a couple of examples in the tree, but it is indeed rare.
> 
> I wanted to avoid casting so that the compiler would still shout at me if data types changed. It’s much easier to miss places where a variable is used (and that need to be updated) if they’re getting cast to something.
> 
You do not need to cast after uintmax_t cast.  Point is that the type is
the highest rank integer on the arch.

Of course, uintmax_t on all existing arches is 64bit, and would stay the same
even after 128bit integers (like long long long) are introduced.  But I do
not think it is relevant there.

> If this is something the project has strong feelings about I’ll change it, but I think I like this slightly better than casting to uintmax_t.
> 
> Best regards,
> Kristof

On Tue, Aug 31, 2021 at 11:03:12AM +0200, Dimitry Andric wrote:
> On 31 Aug 2021, at 01:33, Konstantin Belousov <kostikbel at gmail.com> wrote:
> > 
> > On Sun, Aug 29, 2021 at 07:40:09PM +0200, Dimitry Andric wrote:
> >> On 29 Aug 2021, at 18:00, Kristof Provost <kp at freebsd.org> wrote:
> >>> 
> >>> On 29 Aug 2021, at 17:31, Dimitry Andric wrote:
> >>>> The branch main has been updated by dim:
> >>>> 
> >>>> URL: https://cgit.FreeBSD.org/src/commit/?id=5b8f07b12f8477f1679013d6b3abdab8d33c7243
> >>>> 
> >>>> commit 5b8f07b12f8477f1679013d6b3abdab8d33c7243
> >>>> Author:     Dimitry Andric <dim at FreeBSD.org>
> >>>> AuthorDate: 2021-08-29 15:31:28 +0000
> >>>> Commit:     Dimitry Andric <dim at FreeBSD.org>
> >>>> CommitDate: 2021-08-29 15:31:28 +0000
> >>>> 
> >>>>   Fix -Wformat errors in pfctl on 32-bit architectures
> >>>> 
> >>>>   Use PRIu64 to printf(3) uint64_t quantities, otherwise this will result
> >>>>   in "error: format specifies type 'unsigned long' but the argument has
> >>>>   type 'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat]" on 32-bit
> >>>>   architectures.
> >>>> 
> >>>>   Fixes:          80078d9d38fd
> >>>>   MFC after:      1 week
> >>> 
> >>> Thanks!
> >>> 
> >>> I was running test builds for a fix, but it is so much more convenient when other people fix my mistakes for me.
> >> 
> >> I was trying buildworld on i386 for something totally unrelated, and ran
> >> into these -Wformat errors so I took the liberty of patching them up
> >> quickly. :)
> > 
> > Generally we do not use the PRIu64 (you should remember the term
> > abomination).  Why not cast to uintmax_t and use %ju as we typically do
> > in other places.
> 
> I personally see nothing wrong with PRIu64, but in this case I just
> copied the existing coding style.

Well, PRIu64 is ugly.  %ju is much easier to read and write.

Anyway, I do not insist, just pointing out common practice for this specific
case.