Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 21 Jan 2007 16:01:40 -0700 (MST)
From:      "M. Warner Losh" <imp@bsdimp.com>
To:        max@love2party.net
Cc:        scottl@samsco.org, src-committers@freebsd.org, netchild@freebsd.org, cvs-src@freebsd.org, cvs-all@freebsd.org, sam@errno.com
Subject:   Re: cvs commit: src/sys/compat/linprocfs linprocfs.c
Message-ID:  <20070121.160140.1973605866.imp@bsdimp.com>
In-Reply-To: <200701212037.25404.max@love2party.net>
References:  <20070121131229.014eda2e@Magellan.Leidinger.net> <20070121.084719.-233674217.imp@bsdimp.com> <200701212037.25404.max@love2party.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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.
: 
: 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.

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.

In short, this is a really bad idea.

Warner



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070121.160140.1973605866.imp>