Date: Sun, 20 Jun 2004 01:40:54 +0000 From: Darren Reed <darrenr@hub.freebsd.org> To: Doug Rabson <dfr@nlsystems.com> Cc: David Schultz <das@FreeBSD.org> Subject: Re: cvs commit: src/contrib/pf/pfctl pfctl_parser.c Message-ID: <20040620014054.GA63575@hub.freebsd.org> In-Reply-To: <200406190958.43804.dfr@nlsystems.com> References: <200406171523.i5HFNpjs011498@repoman.freebsd.org> <20040618143127.GP9228@elvis.mu.org> <20040619071754.GA73529@VARK.homeunix.com> <200406190958.43804.dfr@nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jun 19, 2004 at 09:58:43AM +0100, Doug Rabson wrote:
> On Saturday 19 June 2004 08:17, David Schultz wrote:
> > On Fri, Jun 18, 2004, Maxime Henrion wrote:
> > > Dag-Erling Sm?rgrav wrote:
> > > > Max Laier <mlaier@FreeBSD.org> writes:
> > > > > Log:
> > > > > Fix printing of u_int64_t with a cast to unsigned long long.
> > > >
> > > > The correct fix is to cast it to uintmax_t and print it with %ju.
> > >
> > > Using %llu and a cast to (unsigned long long) is as correct as
> > > using uintmax_t and %ju because the C99 standard says that "long
> > > long" is at least 64-bit wide. We generally use {u,}intmax_t in
> > > FreeBSD because it works in more cases, but in that case we can't
> > > because OpenBSD doesn't have intmax_t.
> >
> > /me wonders how much backpedaling we'll wind up doing on the
> > uintmax_t casts when someone decides to add uint128_t to gcc
> > and uintmax_t becomes painfully slow on 32-bit arches. ;-)
>
> Gcc already has uint128_t. I use it all the time on PS2 and something
> like it is used on x86 for SSE...
That's nice! Finally a native type for putting IPv6 addresses in!
Darren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040620014054.GA63575>