lkml.org 
[lkml]   [2022]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v3] Many pages: Document fixed-width types with ISO C naming
From
Date
On Thu, 2022-08-25 at 09:48 +0200, Alejandro Colomar wrote:
> Hi Xi,
>
> On 8/25/22 09:28, Xi Ruoyao wrote:
> > On Thu, 2022-08-25 at 09:20 +0200, Alejandro Colomar via Gcc-patches
> > wrote:
> > > I don't know for sure, and I never pretended to say otherwise.  But what
> > > IMHO the kernel could do is to make the types compatible, by typedefing
> > > to the same fundamental types (i.e., long or long long) that user-space
> > > types do.
> >
> > In user-space things are already inconsistent as we have multiple libc
> > implementations.  Telling every libc implementation to sync their
> > typedef w/o a WG14 decision will only cause "aggressive discussion" (far
> > more aggressive than this thread, I'd say).
> >
> > If int64_t etc. were defined as builtin types since epoch, things would
> > be a lot easier.  But we can't change history.
>
> This would be great.  I mean, the fundamental types should be u8, u16,
> ... and int, long, ... typedefs for these, and not the other way around,
> if the language was designed today.
>
> Maybe GCC could consider something like that.

GCC already have __UINT8_TYPE__ etc. but again telling all libc
implementations to use "typedef __UINT8_TYPE__ uint8_t" etc. will make
no effect expect annoying their maintainers.

--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

\
 
 \ /
  Last update: 2022-08-25 10:10    [W:0.166 / U:0.496 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site