Hi Peter,

Honestly, I think it's probably best practice to use the formatting macros
everywhere. The reason it hasn't been noticed in some of the other
locations you mentioned is because those platforms are architecture
specific where the warning doesn't apply. I'm not sure exactly why it
differs since uint32 is a fixed width, but I've seen this in places that
use %lu for unsigned int instead of %u, etc.

I would go for modifying whatever you can find with the macros if you're
willing, it can't hurt.

Matteo

On Sat, Feb 21, 2026, 6:12 PM Peter Barada <[email protected]> wrote:

> While adding button support to nucleo-h743zi2:jumbo, I ran in six of the
> same warnings in drivers/usbhosty/usbhost_storage.c that are independent
> of the changes I made; here's the first of six warnings in the file:
>
> usbhost/usbhost_storage.c: In function 'usbhost_dumpcbw':
> usbhost/usbhost_storage.c:482:9: warning: format '%x' expects argument of
> type 'unsigned int', but argument 3 has type 'uint32_t' {aka 'long unsigned
> int'} [-Wformat=]
>    482 |   uinfo("  signature: %08x\n", usbhost_getle32(cbw->signature));
>        |         ^~~~~~~~~~~~~~~~~~~~~  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>        |                                |
>        |                                uint32_t {aka long unsigned int}
> usbhost/usbhost_storage.c:482:26: note: format string is defined here
>
> Fixing the warnings are easy in this case - replace '"%08x\n"' with
> '"%08" PRIx32' where the corresponding argument is a uint32_t.
>
> Out of curiosity I greped for '%08x' in the tree the tree and see other
> places where that format is used with uint32_t corresponding argument
> (e.g arch/arm/src/sama5/sam_nand.h::nand_getreg,
> arch/arm/src/am335x/am335x_can.c::can_printreg, etc).
>
> Question is should I create a pull request that makes this substitution
> in just drivers/usbhost/usbhost_storage.c or should it include more
> substitutions of '"%08x"' with '"%08" PRIx32 "' more/all cases where
> %08x format is used with uint32_t typed argument?
>
> --
> Peter Barada
> [email protected]
>

Reply via email to