Re: [PATCH 3/8] sys/types.h: Don’t define u_intN_t or register_t unless __USE_MISC.

[Zack Weinberg <zackw at panix dot com>]

On Thu, May 9, 2019 at 4:34 AM Florian Weimer <fweimer@redhat.com> wrote:
> > +* The typedefs u_int8_t, u_int16_t, u_int32_t, u_int64_t, and register_t
> > +  are no longer defined by <sys/types.h> in strict conformance modes.
> > +  These types were historically provided by <sys/types.h> on BSD systems,
> > +  but are not part of the POSIX specification for that header.  Applications
> > +  requiring fixed-width unsigned integer types should use the similarly
> > +  named uint8_t, uint16_t, etc. from <stdint.h>.  There is no standardized
> > +  replacement for register_t.
>
> The challenge with register_t is that it's long long on x32 and MIPS64
> with -mabi=n32.

Yes, patch 2 of this series had to introduce a MIPS-specific
bits/typesizes.h because of this.

> And ideally, it would be the return type of the syscall function (which
> is long int by incorrect tradition).

I don't want to change that in this patch series.

[sys/types.h]
> > +/* POSIX does not require intN_t to be defined in this header, so
> > +   technically this ought to be under __USE_MISC, but it doesn't
> > +   forbid them to be defined here either, and much existing code
> > +   expects them to be defined here.  */
> > +#include <bits/stdint-intn.h>
...
> > -/* These were defined by ISO C without the first `_'.  */
> > +/* These size-specific names are used by some of the inet code.
> > +   They were defined by ISO C without the first `_'.  */
> >  typedef __uint8_t u_int8_t;
> >  typedef __uint16_t u_int16_t;
> >  typedef __uint32_t u_int32_t;
>
> I think the comment refers to the same types as the comment above the
> inclusion of <bits/stdint-intn.h>.  Maybe that could be made more clear
> to the casual reader?

The important difference here is that intN_t are standard types (but
not standardized as provided by sys/types.h) so it's less troublesome
for us to provide them unconditionally, as existing code expects.
u_intN_t are not standard types so we really shouldn't provide them
unconditionally.  How's this for a comment?

/* These alternative names for uintN_t were used by pre-C99 networking code.
   Provided for backward compatibility only.  */

> Rest of the patch looks fine to me.

Thanks.  Nobody's looked at most of the rest of the patch series; do
you think you might have time to do it in the near future?

zw