From owner-cvs-src@FreeBSD.ORG  Thu Apr 17 00:26:03 2003
Return-Path: <owner-cvs-src@FreeBSD.ORG>
Delivered-To: cvs-src@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 7532737B401; Thu, 17 Apr 2003 00:26:03 -0700 (PDT)
Received: from prince.don.to (host217-44-166-223.range217-44.btcentralplus.com
	[217.44.166.223])	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 4FB4143FCB; Thu, 17 Apr 2003 00:26:01 -0700 (PDT)
	(envelope-from sumikawa@ebina.hitachi.co.jp)
Received: from localhost (localhost [127.0.0.1])
	by prince.don.to (8.12.8/8.11.6) with ESMTP id h3H8NvwZ000845;
	Thu, 17 Apr 2003 08:24:31 GMT
	(envelope-from sumikawa@ebina.hitachi.co.jp)
Date: Thu, 17 Apr 2003 08:23:57 +0000 (GMT)
Message-Id: <20030417.082357.81502723.sumikawa@ebina.hitachi.co.jp>
To: nectar@FreeBSD.org
From: Munechika Sumikawa <sumikawa@ebina.hitachi.co.jp>
In-Reply-To: <20030416124657.GD72501@madman.celabo.org>
References: <200304161121.h3GBLDhJ040405@repoman.freebsd.org>
	<20030416124657.GD72501@madman.celabo.org>
X-Mailer: xcite1.48> Mew version 3.2rc1 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
cc: cvs-src@FreeBSD.org
cc: sumikawa@FreeBSD.org
cc: cvs-all@FreeBSD.org
cc: src-committers@FreeBSD.org
cc: sumikawa@ebina.hitachi.co.jp
Subject: Re: cvs commit: src/lib/libipsec pfkey_dump.c
X-BeenThere: cvs-src@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: CVS commit messages for the src tree <cvs-src.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-src>
List-Post: <mailto:cvs-src@freebsd.org>
List-Help: <mailto:cvs-src-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Apr 2003 07:26:04 -0000

nectar> These sizes seem arbitrary.  Previously, at 10 bytes, they were just a
nectar> bit too small to hold the representation of the largest 32-bit
nectar> unsigned integer.  Now at 20 bytes, they are just a bit too small to
nectar> hold the representation of the largest 64-bit unsigned integer.  This
nectar> seems sloppy.  (As does using a 128 byte buffer to hold the result of
nectar> concatenating two 20 byte buffers.)

You are right.  I've changed to 128 bytes.  It can be used until we
support 512bit CPU :-)

-- Sumikawa