On Mon, Dec 22, 2025 at 05:18:26PM -0500, Michael S. Tsirkin wrote: > On Mon, Dec 22, 2025 at 11:43:52AM +0100, Thomas Weißschuh wrote: > > On Mon, Dec 22, 2025 at 05:28:30AM -0500, Michael S. Tsirkin wrote: > > > On Mon, Dec 22, 2025 at 11:22:16AM +0100, Thomas Weißschuh wrote: > > > > On Mon, Dec 22, 2025 at 03:39:12AM -0500, Michael S. Tsirkin wrote: > > > > > On Mon, Dec 22, 2025 at 09:00:33AM +0100, Thomas Weißschuh wrote: > > > > > > Using libc types and headers from the UAPI headers is problematic > > > > > > as it > > > > > > introduces a dependency on a full C toolchain. > > > > > > > > > > > > On Linux 'unsigned long' works as a replacement for 'uintptr_t' and > > > > > > does > > > > > > not depend on libc. > > > > > > > > > > > > Signed-off-by: Thomas Weißschuh <[email protected]> > > > > > > > > > > > > > > > are you fixing other uses of uintptr_t ? > > > > > > > > I am focussing on UAPI headers which include libc headers. > > > > virtio_ring.h seems to be the only such header which uses uintptr_t. > > > > There are a few other UAPI headers which reference uintptr_t, but only > > > > in comments or macros. > > > > > > > > uintptr_t in regular kernel code is out of scope for me. > > > > While it is iffy, it doesn't actually hurt. > > > > > > > > > > > > Thomas > > > > > > And other uses of stdint.h? > > > > If they are in UAPI headers I will look at them. > > I also have a series prepared to prevent new users from creeping in. > > I don't mind picking this but I'm just curious what's driving all this > effort.
It started with a recent change to an UAPI header which introduced a dependency on libc that broke some things I was doing. See the fix and background in [0]. So I looked into catching such issues earlier, which resulted in [1]. Fortunately there are not many problematic headers [2] in general, so I am now also fixing those, so the new check can validate more headers and prevent more regressions. [0] https://lore.kernel.org/lkml/[email protected]/ [1] https://lore.kernel.org/lkml/[email protected]/ [2] https://lore.kernel.org/lkml/[email protected]/ Thomas
