From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 7 07:04:41 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3451E16A4CE; Sun, 7 Mar 2004 07:04:41 -0800 (PST) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24F5943D1F; Sun, 7 Mar 2004 07:04:41 -0800 (PST) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i27F4f9Q079787; Sun, 7 Mar 2004 07:04:41 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i27F4emg079786; Sun, 7 Mar 2004 07:04:41 -0800 (PST) (envelope-from rizzo) Date: Sun, 7 Mar 2004 07:04:40 -0800 From: Luigi Rizzo To: Maxime Henrion Message-ID: <20040307070440.A79457@xorpc.icir.org> References: <20040306111922.GA64109@numeri.campus.luth.se> <20040306082625.B34490@xorpc.icir.org> <20040306173219.GB64109@numeri.campus.luth.se> <20040306212233.A56351@xorpc.icir.org> <20040307113008.GC64109@numeri.campus.luth.se> <20040307140915.GR35475@elvis.mu.org> <20040307141643.GS35475@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040307141643.GS35475@elvis.mu.org>; from mux@freebsd.org on Sun, Mar 07, 2004 at 03:16:43PM +0100 cc: ipfw@freebsd.org cc: Johan Karlsson Subject: Re: where do %j/uintmax_t stand in terms of standards? [WAS: Re: WARNS cleanup for ipfw X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2004 15:04:41 -0000 On Sun, Mar 07, 2004 at 03:16:43PM +0100, Maxime Henrion wrote: ... [thanks for the clarification about %llu vs %qu] > > before). It is correct to cast to unsigned long long and use "%llu" to > > print an uint64_t because a long long is guaranteed to always be at > > least 64 bits. One should however still use uint64_t to store the type yes, my point against casts was that given that we are going for some code cleanup, we might also do it right and make sure there are no aligmnent issues by using align_uint64() and making it return the correct type so we need no casts. > those in FreeBSD because they are simply ugly. Also, it's probably not > a good idea to use this in ipfw since Luigi is concerned about keeping > the code similar in 5.x and 4.x. yep cheers luigi