[PATCH] Use the standard libc types in fatattr

Laszlo Papp lpapp at kde.org
Sat Jul 5 11:20:51 UTC 2014


On Sat, Jul 5, 2014 at 12:38 AM, Isaac Dunham <ibid.ag at gmail.com> wrote:

> On Fri, Jul 04, 2014 at 03:06:04PM +0100, Laszlo Papp 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.
>
> To be pedantic, uint32_t was introduced in the Open Group Base
> Specifications, Issue 5 (released in 1997, basis for UNIX98).
> At that point it was defined in <inttypes.h>, which only defined
> (u)int*_t.
>
> As far as when <inttypes.h> was available, it was first shipped in glibc
> 2.1
> (and prereleases thereof), meaning it was first packaged in Debian 2.1
> (slink) on sparc.  Slink shipped with kernel 2.0.36.
> But the names of sized types in the kernel _could_ have been switched
> over when the standard was released, or rather during any of the "unstable"
> series after that; this is not a compiler change but a header change,
> and the kernel has its own headers. Kernel 2.0 was released in 1996
> (before the standard), but 2.2, 2.4, and 2.6 were released in 1999,
> 2001, and 2003.
>

Glibc is not the only thing, in fact it has not been used much in embedded,
and even today, it is mostly for "computing embedded".


>
> The real reason is mentioned in the kernel coding style manual:
> some people don't like the "new" types.
>

Tes... for good: "do not fix what is not broken".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20140705/5b0f35fd/attachment-0001.html>


More information about the busybox mailing list