unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Zack Weinberg <zackw@panix.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [PATCH 3/8] sys/types.h: Don’t define u_intN_t or register_t unless __USE_MISC.
Date: Wed, 22 May 2019 10:34:05 -0400	[thread overview]
Message-ID: <CAKCAbMggqQeQ2TLsSbLuVYr8hwhp80dj+TiQhGZZXaurTy8U2w@mail.gmail.com> (raw)
In-Reply-To: <878svgt4au.fsf@oldenburg2.str.redhat.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

  reply	other threads:[~2019-05-22 14:34 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-11 14:59 [PATCH 0/8] sys/types.h cleanup and further typedef obsoletion Zack Weinberg
2019-03-11 14:59 ` [PATCH 1/8] Move inttypes.h and stdint.h to stdlib Zack Weinberg
2019-03-11 23:19   ` Joseph Myers
2019-03-13 13:46     ` Zack Weinberg
2019-03-11 14:59 ` [PATCH 2/8] Define register_t using bits/typesizes.h macros Zack Weinberg
2019-05-22 14:42   ` Florian Weimer
2019-05-22 15:31     ` Zack Weinberg
2019-05-22 16:27       ` Florian Weimer
2019-03-11 14:59 ` [PATCH 3/8] sys/types.h: Don’t define u_intN_t or register_t unless __USE_MISC Zack Weinberg
2019-05-09  8:34   ` Florian Weimer
2019-05-22 14:34     ` Zack Weinberg [this message]
2019-03-11 14:59 ` [PATCH 4/8] Add caddr_t, daddr_t, and loff_t to the set of obsolete typedefs Zack Weinberg
2019-03-11 14:59 ` [PATCH 5/8] Simplify definition of __time64_t Zack Weinberg
2019-05-22 14:44   ` Florian Weimer
2019-03-11 14:59 ` [PATCH 6/8] Clean up bits/types.h Zack Weinberg
2019-03-11 14:59 ` [PATCH 7/8] Create bits/types headers for most remaining __T_defined macros Zack Weinberg
2019-03-11 14:59 ` [PATCH 8/8] Don’t conditionalize declarations of ldiv_t, lldiv_t, __gwchar_t Zack Weinberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/libc/involved.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKCAbMggqQeQ2TLsSbLuVYr8hwhp80dj+TiQhGZZXaurTy8U2w@mail.gmail.com \
    --to=zackw@panix.com \
    --cc=fweimer@redhat.com \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).