Re: [PATCH] Add __intNN_t type definitions

[Rich Felker <dalias@libc.org>]

On Fri, Jan 12, 2018 at 07:04:09PM +0100, Markus Wichmann wrote:
> On Fri, Jan 12, 2018 at 05:07:05PM +0000, Rostislav Skudnov wrote:
> > These types are defined in glibc headers and are used by some programs,
> > e. g. xfsprogs before version 4.13.0.
> 
> Then those programs are broken and have to be patched.
> 
> > ---
> >  include/sys/types.h | 9 +++++++++
> >  1 file changed, 9 insertions(+)
> > 
> > diff --git a/include/sys/types.h b/include/sys/types.h
> > index 75e489c..b02208d 100644
> > --- a/include/sys/types.h
> > +++ b/include/sys/types.h
> > @@ -56,6 +56,15 @@ extern "C" {
> >  
> >  #include <bits/alltypes.h>
> >  
> > +typedef signed char __int8_t;
> > +typedef unsigned char __uint8_t;
> > +typedef short __int16_t;
> > +typedef unsigned short __uint16_t;
> > +typedef int __int32_t;
> > +typedef unsigned int __uint32_t;
> > +typedef off_t __int64_t;
> > +typedef ino_t __uint64_t;
> > +
> >  #if defined(_GNU_SOURCE) || defined(_BSD_SOURCE)
> >  typedef unsigned char u_int8_t;
> >  typedef unsigned short u_int16_t;
> > -- 
> > 2.1.4
> > 
> 
> Names starting with two underscores (or one underscore and one capital
> letter) are reserved for internal use by the implementation. Unless they
> are specifically defined (like _Bool), they should not be used.

Yes, this is a known application bug and not usage we will support.
It's not like other cases where types or symbols that were
inadvertently named with leading underscores and entered common use,
which sometimes make sense to support if they're the only way to do
something. This is just applications gratuitously using the wrong name
when the right one exists alongside it.

Rich