Re: [PATCH v6 2/3] iio: light: add support for veml6046x00 RGBIR color sensor

[Andy Shevchenko <andy.shevchenko@gmail.com>]

Fri, Aug 22, 2025 at 08:39:35AM +0300, Matti Vaittinen kirjoitti:
> On 21/08/2025 21:53, Andreas Klinger wrote:
> > Andy Shevchenko <andriy.shevchenko@linux.intel.com> schrieb am Do, 21. Aug 12:43:
> > > > > > +	part_id = le16_to_cpu(reg);
> > > > > > +	if (part_id != 0x0001)
> > > > > > +		dev_info(dev, "Unknown ID %#04x\n", part_id);
> > > > > 
> > > > > For 0 it will print 0 and not 0x0000. Is it okay?
> > > > 
> > > > I just tried and it prints 0x00 if the part_id is 0.
> > > 
> > > This is interesting... So it's not 0, nor 0x0000?
> > 
> > No. It prints 0x00 on my BeagleBoneBlack with kernel 6.16.0-rc5.
> 
> I think this makes sense because of the '#' -flag. The "0x" is appended
> because of it, and this consumes 2 characters from the 4 character field,
> leaving only 2 chars left for the value.
> 
> What I find interesting is that gcc on my PC does:
> 
>         printf("%#04x\n", 0);
>         printf("%#04x\n", 1);
>         printf("%#04x\n", 10);
>         printf("%#04x\n", 17);
> 
> 0000
> 0x01
> 0x0a
> 0x11
> 
> gcc version 15.2.1 20250808 (Red Hat 15.2.1-1) (GCC)
> 
> It'd be nice to learn why the zero is treated differently? Andy, did you
> have some insight as you asked this?

Nice, we have so many variants now on how to treat 0 with %#x cases...
My understanding was that it should print plain 0 without even 0x prefix, but
since we specify 04 it prints 4 of them, so this behaviour seems consistent to
me, the 0x00 case seems buggy.

Now to the standards...

https://pubs.opengroup.org/onlinepubs/9699919799/functions/fprintf.html

Read this:
"For x or X conversion specifiers, a **non-zero** result shall have 0x (or 0X) prefixed to it."

** -- is my marking to make a point.

So, 0x00 is a bug in Andreas case and has to be fixed somewhere.

-- 
With Best Regards,
Andy Shevchenko