From: Florian Weimer <fweimer@redhat.com>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: Arnd Bergmann <arnd@arndb.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>,
LTP List <ltp@lists.linux.it>,
GNU C Library <libc-alpha@sourceware.org>,
linux-arch <linux-arch@vger.kernel.org>
Subject: Re: [PATCH] uapi: Make __{u,s}64 match {u,}int64_t in userspace
Date: Tue, 23 Nov 2021 20:50:31 +0100 [thread overview]
Message-ID: <87a6hups6w.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <YZyw56flmdQnBIuh@yuki> (Cyril Hrubis's message of "Tue, 23 Nov 2021 10:14:15 +0100")
* Cyril Hrubis:
> As far as I can tell the userspace bits/types.h does exactly the same
> check in order to define uint64_t and int64_t, i.e.:
>
> #if __WORDSIZE == 64
> typedef signed long int __int64_t;
> typedef unsigned long int __uint64_t;
> #else
> __extension__ typedef signed long long int __int64_t;
> __extension__ typedef unsigned long long int __uint64_t;
> #endif
>
> The macro __WORDSIZE is defined per architecture, and it looks like the
> defintions in glibc sources in bits/wordsize.h match the uapi
> asm/bitsperlong.h. But I may have missed something, the code in glibc is
> not exactly easy to read.
__WORDSIZE isn't exactly a standard libc macro.
On musl, x86-64 x32 has __WORDSIZE == 64 depending on header-inclusion
order, but that's probably just a bug.
Thanks,
Florian
WARNING: multiple messages have this Message-ID (diff)
From: Florian Weimer <fweimer@redhat.com>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: linux-arch <linux-arch@vger.kernel.org>,
GNU C Library <libc-alpha@sourceware.org>,
Arnd Bergmann <arnd@arndb.de>,
Linux API <linux-api@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
LTP List <ltp@lists.linux.it>
Subject: Re: [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t in userspace
Date: Tue, 23 Nov 2021 20:50:31 +0100 [thread overview]
Message-ID: <87a6hups6w.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <YZyw56flmdQnBIuh@yuki> (Cyril Hrubis's message of "Tue, 23 Nov 2021 10:14:15 +0100")
* Cyril Hrubis:
> As far as I can tell the userspace bits/types.h does exactly the same
> check in order to define uint64_t and int64_t, i.e.:
>
> #if __WORDSIZE == 64
> typedef signed long int __int64_t;
> typedef unsigned long int __uint64_t;
> #else
> __extension__ typedef signed long long int __int64_t;
> __extension__ typedef unsigned long long int __uint64_t;
> #endif
>
> The macro __WORDSIZE is defined per architecture, and it looks like the
> defintions in glibc sources in bits/wordsize.h match the uapi
> asm/bitsperlong.h. But I may have missed something, the code in glibc is
> not exactly easy to read.
__WORDSIZE isn't exactly a standard libc macro.
On musl, x86-64 x32 has __WORDSIZE == 64 depending on header-inclusion
order, but that's probably just a bug.
Thanks,
Florian
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2021-11-23 19:50 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-22 16:43 [PATCH] uapi: Make __{u,s}64 match {u,}int64_t in userspace Cyril Hrubis
2021-11-22 16:43 ` [LTP] " Cyril Hrubis
2021-11-22 16:51 ` Alejandro Colomar (mailing lists)
2021-11-22 16:51 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Alejandro Colomar (mailing lists)
2021-11-22 20:48 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Arnd Bergmann
2021-11-22 20:48 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Arnd Bergmann
2021-11-23 9:14 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Cyril Hrubis
2021-11-23 9:14 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Cyril Hrubis
2021-11-23 14:18 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Arnd Bergmann
2021-11-23 14:18 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Arnd Bergmann
2021-11-23 19:50 ` Florian Weimer [this message]
2021-11-23 19:50 ` Florian Weimer
2021-11-24 10:17 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Alejandro Colomar (man-pages)
2021-11-24 10:17 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Alejandro Colomar (man-pages)
2021-11-22 22:19 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Zack Weinberg
2021-11-22 22:19 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Zack Weinberg
2021-11-23 9:15 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Cyril Hrubis
2021-11-23 9:15 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Cyril Hrubis
2021-12-02 15:34 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Rich Felker
2021-12-02 15:34 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Rich Felker
2021-12-02 23:29 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Rich Felker
2021-12-02 23:29 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Rich Felker
2021-12-02 23:43 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Adhemerval Zanella
2021-12-02 23:43 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Adhemerval Zanella
2021-12-03 0:10 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Zack Weinberg
2021-12-03 0:10 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Zack Weinberg
2021-12-03 12:32 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Adhemerval Zanella
2021-12-03 12:32 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Adhemerval Zanella
2021-12-03 12:54 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Alejandro Colomar (man-pages)
2021-12-03 12:54 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Alejandro Colomar (man-pages)
2021-11-23 16:47 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " David Howells
2021-11-23 16:47 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " David Howells
2021-11-23 16:58 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " David Laight
2021-11-23 16:58 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " David Laight
2021-11-29 11:58 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Cyril Hrubis
2021-11-29 11:58 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Cyril Hrubis
2021-11-29 14:34 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Arnd Bergmann
2021-11-29 14:34 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Arnd Bergmann
2021-12-02 14:55 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Zack Weinberg
2021-12-02 14:55 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Zack Weinberg
2021-12-02 15:01 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " David Howells
2021-12-02 15:01 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " David Howells
2021-12-02 20:48 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Zack Weinberg
2021-12-02 20:48 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Zack Weinberg
2021-12-08 15:33 ` [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Cyril Hrubis
2021-12-08 15:33 ` [LTP] [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Cyril Hrubis
2022-06-17 12:13 ` Ping: [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Alejandro Colomar
2022-06-17 12:13 ` [LTP] Ping: [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Alejandro Colomar
2022-06-17 15:04 ` Ping: [PATCH] uapi: Make __{u,s}64 match {u,}int64_t " Cyril Hrubis
2022-06-17 15:04 ` [LTP] Ping: [PATCH] uapi: Make __{u, s}64 match {u, }int64_t " Cyril Hrubis
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a6hups6w.fsf@oldenburg.str.redhat.com \
--to=fweimer@redhat.com \
--cc=arnd@arndb.de \
--cc=chrubis@suse.cz \
--cc=libc-alpha@sourceware.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ltp@lists.linux.it \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.