[PATCH] Use the standard libc types in fatattr

Rich Felker dalias at libc.org
Fri Jul 4 14:40:13 UTC 2014


On Fri, Jul 04, 2014 at 04:25:11PM +0200, Denys Vlasenko wrote:
> On Fri, Jul 4, 2014 at 4:06 PM, Laszlo Papp <lpapp at kde.org> wrote:
> > On Fri, Jul 4, 2014 at 2:47 PM, Denys Vlasenko <vda.linux at googlemail.com>
> > wrote:
> >>
> >> On Fri, Jul 4, 2014 at 3:26 PM, Laszlo Papp <lpapp at kde.org> wrote:
> >> >> > -# define FAT_IOCTL_GET_ATTRIBUTES        _IOR('r', 0x10, __u32)
> >> >> > -# define FAT_IOCTL_SET_ATTRIBUTES        _IOW('r', 0x11, __u32)
> >> >> > +# define FAT_IOCTL_GET_ATTRIBUTES        _IOR('r', 0x10, uint32_t)
> >> >> > +# define FAT_IOCTL_SET_ATTRIBUTES        _IOW('r', 0x11, uint32_t)
> >> >> >  #endif
> >> >> >
> >> >> >  /* Currently supports only the FAT flags, not the NTFS ones.
> >> >>
> >> >>
> >> >> Applied, thanks!
> >> >>
> >> >> (why kernel doesn't just use std types?...)
> >> >
> >> > What do you mean by "std types"?
> >>
> >> Like uint32_t
> >
> >
> > As indicated before, it was only introduced in C99. The kernel project
> > predates that for one.
> 
> I understand that.
> It's 2014.
> 15 years to convert to (now-)standard type should be doable.

Yes. If the kernel would convert to using the stdint.h types and
provide its own stdint.h for use with -nostdinc when building the
kernel itself, the kernel headers would automatically be compatible
with userspace when used directly by applications like busybox.

On the other hand, if the kernel headers are intended to be used for
implementing some libc headers, they cannot depend on or pull in
stdint.h unless the corresponding libc header is allowed to do so; if
they did so, it would be namespace pollution. I suspect this is one of
the reasons they may be hesitant to use these types. Right now, all of
their wacky types are in the reserved namespace (double-underscore
prefix) and thus they don't have to worry about it.

Of course libc implementations should not be using kernel headers -- I
thought we learned that lesson 20 years ago with libc5 -- but uclibc
does so heavily and glibc even resurrected the practice at some point
for various things (especially socket stuff, and lots more on some
archs).

Rich


More information about the busybox mailing list