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
next prev parent 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).