From: Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org>
To: Rich Felker <dalias@libc.org>, Zack Weinberg <zack@owlfolio.org>
Cc: linux-arch@vger.kernel.org, linux-api@vger.kernel.org,
libc-alpha@sourceware.org, linux-kernel@vger.kernel.org,
ltp@lists.linux.it
Subject: Re: [PATCH] uapi: Make __{u,s}64 match {u,}int64_t in userspace
Date: Thu, 2 Dec 2021 20:43:19 -0300 [thread overview]
Message-ID: <855a47d1-a89c-bbc8-7ddd-b89104c6138a@linaro.org> (raw)
In-Reply-To: <20211202232954.GI7074@brightrain.aerifal.cx>
On 02/12/2021 20:29, Rich Felker wrote:
> On Thu, Dec 02, 2021 at 10:34:23AM -0500, Rich Felker wrote:
>> On Mon, Nov 22, 2021 at 10:19:59PM +0000, Zack Weinberg via Libc-alpha wrote:
>>> On Mon, Nov 22, 2021, at 4:43 PM, Cyril Hrubis wrote:
>>>> This changes the __u64 and __s64 in userspace on 64bit platforms from
>>>> long long (unsigned) int to just long (unsigned) int in order to match
>>>> the uint64_t and int64_t size in userspace.
>>> ....
>>>> +
>>>> +#include <asm/bitsperlong.h>
>>>> +
>>>> /*
>>>> - * int-ll64 is used everywhere now.
>>>> + * int-ll64 is used everywhere in kernel now.
>>>> */
>>>> -#include <asm-generic/int-ll64.h>
>>>> +#if __BITS_PER_LONG == 64 && !defined(__KERNEL__)
>>>> +# include <asm-generic/int-l64.h>
>>>> +#else
>>>> +# include <asm-generic/int-ll64.h>
>>>> +#endif
>>>
>>> I am all for matching __uN / __sN to uintN_t / intN_t in userspace, but may I suggest the technically simpler and guaranteed-to-be-accurate
>>>
>>> /*
>>> - * int-ll64 is used everywhere now.
>>> + * int-ll64 is used everywhere in kernel now.
>>> + * In user space match <stdint.h>.
>>> */
>>> +#ifdef __KERNEL__
>>> # include <asm-generic/int-ll64.h>
>>> +#elif __has_include (<bits/types.h>)
>>> +# include <bits/types.h>
>>> +typedef __int8_t __s8;
>>> +typedef __uint8_t __u8;
>>> +typedef __int16_t __s16;
>>> +typedef __uint16_t __u16;
>>> +typedef __int32_t __s32;
>>> +typedef __uint32_t __u32;
>>> +typedef __int64_t __s64;
>>> +typedef __uint64_t __u64;
>>> +#else
>>> +# include <stdint.h>
>>> +typedef int8_t __s8;
>>> +typedef uint8_t __u8;
>>> +typedef int16_t __s16;
>>> +typedef uint16_t __u16;
>>> +typedef int32_t __s32;
>>> +typedef uint32_t __u32;
>>> +typedef int64_t __s64;
>>> +typedef uint64_t __u64;
>>> +#endif
>>>
>>> The middle clause could be dropped if we are okay with all uapi
>>> headers potentially exposing the non-implementation-namespace names
>>> defined by <stdint.h>. I do not know what the musl libc equivalent
>>> of <bits/types.h> is.
>>
>> We (musl) don't have an equivalent header or __-prefixed versions of
>> these types.
>>
>> FWIW I don't think stdint.h exposes anything that would be problematic
>> alongside arbitrary use of kernel headers.
>
> Also, per glibc's bits/types.h:
>
> /*
> * Never include this file directly; use <sys/types.h> instead.
> */
>
> it's not permitted (not supported usage) to #include <bits/types.h>.
> So I think the above patch is wrong for glibc too. As I understand it,
> this is general policy for bits/* -- they're only intended to work as
> included by the libc system headers, not directly by something else.
You are right, the idea is to allow glibc to create and remove internal headers.
next prev parent reply other threads:[~2021-12-02 23:43 UTC|newest]
Thread overview: 25+ 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:51 ` Alejandro Colomar (mailing lists) via Libc-alpha
2021-11-22 20:48 ` Arnd Bergmann
2021-11-23 9:14 ` Cyril Hrubis
2021-11-23 14:18 ` Arnd Bergmann
2021-11-23 19:50 ` Florian Weimer via Libc-alpha
2021-11-24 10:17 ` Alejandro Colomar (man-pages) via Libc-alpha
2021-11-22 22:19 ` Zack Weinberg via Libc-alpha
2021-11-23 9:15 ` Cyril Hrubis
2021-12-02 15:34 ` Rich Felker
2021-12-02 23:29 ` Rich Felker
2021-12-02 23:43 ` Adhemerval Zanella via Libc-alpha [this message]
2021-12-03 0:10 ` Zack Weinberg via Libc-alpha
2021-12-03 12:32 ` Adhemerval Zanella via Libc-alpha
2021-12-03 12:54 ` Alejandro Colomar (man-pages) via Libc-alpha
2021-11-23 16:47 ` David Howells via Libc-alpha
2021-11-23 16:58 ` David Laight via Libc-alpha
2021-11-29 11:58 ` Cyril Hrubis
2021-11-29 14:34 ` Arnd Bergmann
2021-12-02 14:55 ` Zack Weinberg via Libc-alpha
2021-12-02 15:01 ` David Howells via Libc-alpha
2021-12-02 20:48 ` Zack Weinberg via Libc-alpha
2021-12-08 15:33 ` Cyril Hrubis
2022-06-17 12:13 ` Ping: " Alejandro Colomar via Libc-alpha
2022-06-17 15:04 ` 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
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=855a47d1-a89c-bbc8-7ddd-b89104c6138a@linaro.org \
--to=libc-alpha@sourceware.org \
--cc=adhemerval.zanella@linaro.org \
--cc=dalias@libc.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ltp@lists.linux.it \
--cc=zack@owlfolio.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).