On Sat, Jul 5, 2014 at 12:38 AM, Isaac Dunham <[email protected]> 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 <[email protected] > > > > wrote: > > > > > On Fri, Jul 4, 2014 at 3:26 PM, Laszlo Papp <[email protected]> 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".
_______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
