[PATCH] Use the standard libc types in fatattr

Rich Felker dalias at libc.org
Sat Jul 5 12:51:45 UTC 2014


On Sat, Jul 05, 2014 at 12:20:51PM +0100, Laszlo Papp wrote:
> > 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".

>From a header standpoint, uClibc effectively is (an old version of)
glibc. From well after the standard types were added. So this is not
an argument against using them.

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

"Do not fix what is not broken" does not apply here. The kernel
headers have ALWAYS been broken for use in userspace. The UAPI effort
has partly fixed this (and is evidence that they _are_ trying to fix
this, albeit poorly).

Rich


More information about the busybox mailing list