Date: Mon, 22 Jan 2007 15:06:09 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: "M. Warner Losh" <imp@bsdimp.com> Cc: scottl@samsco.org, src-committers@freebsd.org, netchild@freebsd.org, cvs-src@freebsd.org, cvs-all@freebsd.org, sam@errno.com, max@love2party.net Subject: Re: cvs commit: src/sys/compat/linprocfs linprocfs.c Message-ID: <20070122142605.Q7387@besplex.bde.org> In-Reply-To: <20070121.160140.1973605866.imp@bsdimp.com> References: <20070121131229.014eda2e@Magellan.Leidinger.net> <20070121.084719.-233674217.imp@bsdimp.com> <200701212037.25404.max@love2party.net> <20070121.160140.1973605866.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 21 Jan 2007, M. Warner Losh wrote: > In message: <200701212037.25404.max@love2party.net> > Max Laier <max@love2party.net> writes: > : On Sunday 21 January 2007 16:47, M. Warner Losh wrote: > : > In message: <20070121131229.014eda2e@Magellan.Leidinger.net> > : > > : > Alexander Leidinger <netchild@freebsd.org> writes: > : > : I was thinking more about something like: > : > : to print identifier to use in the > : > : kernel sizeof() %zd > : > : int64_t xyz > : > : int32_t klm > : > : ... ... > : > > : > The last two aren't possible to print without casts, or the PRI_xxx > : > macros. Printing of most typedefed ntypes isn't possible without casts (to [u]intmax_t for integral types), or _with_ the PRIxxx macros (since the size of the type should be opaque, but you have to know the size to encoded it in the xxx, but then in many cases you can more easily encode the size in the cast). > : > : That's right, but I think we can fix it by simply making int64_t an alias > : for "long long" on all architectures. I still haven't heard any reason > : not to just do this - is there something, other than historical? > > The short answer is because long long and long are different types. > Changing the underlying type for uint64_t and friends would break > user's code as the underlying type changes. I think most user code wouldn't break now. It is just unportable to assume that int64_t == long long == intmax_t. int64_t is untentionally made != long long if possible so that this mistake is not made again (previous generations of it assumed int16_t == int, then int == int32_t == long). All that is guaranteed is that int64_t <= long long <= intmax_t. It may be a bug that intmax_t is declared to be int64_t == long on arches with 64-bit longs, but since sizeof(int64_t) == sizeof(long long) on all supported arches, this is the only way of inhibiting assumptions that long long == intmax_t. > And it isn't portable, which would make code written for FreeBSD much > less portable. The only portable way is to use the PRI* macros. We > can paper over this fact, kinda, in FreeBSD. So long as we never have > an architecture where long long isn't 128 bits. Using the PRI* macros is far less portable, or at least far more ugly. You would have to do the equivalent of defining PRIfoo_t for each typedefed type foo_t used by the system. Put these in an OS-specific header and be unportable, or generate them in each application or source file and be ugly. With -Wformat, you cannot even avoid the problem that sizeof() doesn't work in cpp expressions by using sizeof() to select the format in an if-else or case statement, since -Wformat will complain about the format errors in unreachable code. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070122142605.Q7387>