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 <[email protected]> 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 <[email protected]> >>>> AuthorDate: 2021-08-29 15:31:28 +0000 >>>> Commit: Dimitry Andric <[email protected]> >>>> 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. 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 _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all To unsubscribe, send any mail to "[email protected]"
