Date: Tue, 17 Nov 2015 10:09:06 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Benjamin Kaduk <kaduk@MIT.EDU> Cc: Warner Losh <imp@bsdimp.com>, Justin Hibbits <chmeeedalf@gmail.com>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: CFT: uintmax_t rman Message-ID: <20151117080906.GA58629@kib.kiev.ua> In-Reply-To: <alpine.GSO.1.10.1511161923000.26829@multics.mit.edu> References: <75C2B97F-3C5E-49E3-A584-DE84463889FC@gmail.com> <0F3B8FF2-E54E-446F-8D4E-415A1111EF4D@bsdimp.com> <alpine.GSO.1.10.1511161923000.26829@multics.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Nov 16, 2015 at 07:25:54PM -0500, Benjamin Kaduk wrote:
> Channeling my inner bde (maybe?), the typedef is probably helpful, but
> uintmax_t seems less so. uintmax_t has no guaranteed ABI, so a
> fixed-width type like uint64_t seems beter, assuming that uintmax_t is
> currently uint64_t everywhere (which I think is the case but did not
> verify).
The statement about {u}intmax_t not having a guaranteed ABI is wrong,
I believe. You cannot change the type after it is exposed.
I am sure that ANSI C or POSIX would introduce intthistimerealmax_t after
long long long type is added (only half-joking).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151117080906.GA58629>