[PATCH] Use the standard libc types in fatattr

[Laszlo Papp]

On Sat, Jul 5, 2014 at 1:51 PM, Rich Felker <dalias at libc.org> wrote:

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

I was not even referring to uClibc, eventually ...


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

Just because you have a different personal style, it does not mean it is
broken. It has served and made Linux popular for well over a decade and a
half.

Again, I like the bikeshed pink.


>
> Rich
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20140705/c266d2ae/attachment.html>