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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aKgjU6Pqhaj8oTqO@pixelbook>
Date: Fri, 22 Aug 2025 10:59:15 +0300
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Andy Shevchenko <andy.shevchenko@...il.com>,
	Rasmus Villemoes <linux@...musvillemoes.dk>
Cc: Matti Vaittinen <mazziesaccount@...il.com>,
	Andreas Klinger <ak@...klinger.de>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	jic23@...nel.org, robh@...nel.org, krzk+dt@...nel.org,
	conor+dt@...nel.org, lars@...afoo.de,
	javier.carrasco.cruz@...il.com, arthur.becker@...tec.com,
	perdaniel.olsson@...s.com, mgonellabolduc@...onoff.com,
	muditsharma.info@...il.com, clamor95@...il.com,
	emil.gedenryd@...s.com, devicetree@...r.kernel.org,
	linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 2/3] iio: light: add support for veml6046x00 RGBIR
 color sensor

Fri, Aug 22, 2025 at 10:23:56AM +0300, Andy Shevchenko kirjoitti:
> 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@...ux.intel.com> schrieb am Do, 21. Aug 12:43:

+Cc: Rasmus (I am wondering what your opinion is on %#x for plain 0)

...

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

Note, even if we want to deviate the kernel implementation, the 0x00 is still
buggy since 04 defines *minimum* digits of the *value* to be printed. 0x00
prints only 2 out of 4.

-- 
With Best Regards,
Andy Shevchenko