[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <YqyX7E954/b+yKS3@yuki>
Date: Fri, 17 Jun 2022 17:04:12 +0200
From: Cyril Hrubis <chrubis@...e.cz>
To: Alejandro Colomar <alx.manpages@...il.com>
Cc: "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
libc-alpha@...rceware.org,
"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
David Laight <David.Laight@...lab.com>,
Zack Weinberg <zack@...folio.org>,
"ltp@...ts.linux.it" <ltp@...ts.linux.it>,
David Howells <dhowells@...hat.com>
Subject: Re: Ping: [PATCH] uapi: Make __{u,s}64 match {u,}int64_t in userspace
Hi!
> >>> I could be persuaded otherwise with an example of a program for which
> >>> changing __s64 from 'long long' to 'long' would break *binary* backward
> >>> compatibility, or similarly for __u64.
> >>
> >> C++ could break.
> >
> > Thinking of this again we can detect C++ as well so it can be safely
> > enabled just for C with:
> >
> > #if !defined(__KERNEL__) && !defined(__cplusplus) && __BITSPERLONG == 64
> > # include <asm-generic/int-l64.h>
> > #else
> > # include <asm-generic/int-ll64.h>
> > #endif
> >
>
> I'm very interested in seeing this merged, as that would allow
> simplifying the man-pages by removing unnecessary kernel details such as
> u64[1]. How is the state of this patch?
I guess that it stalled because I haven't posted it as an actual patch,
I should do so to get this back on a track.
--
Cyril Hrubis
chrubis@...e.cz
Powered by blists - more mailing lists