From owner-cvs-all@FreeBSD.ORG Wed Apr 16 05:47:00 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32CD037B401; Wed, 16 Apr 2003 05:46:59 -0700 (PDT) Received: from gw.nectar.cc (gw.nectar.cc [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0736343F93; Wed, 16 Apr 2003 05:46:59 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.nectar.cc (Postfix) with ESMTP id 90D695D; Wed, 16 Apr 2003 07:46:58 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id E9A9A78C44; Wed, 16 Apr 2003 07:46:57 -0500 (CDT) Date: Wed, 16 Apr 2003 07:46:57 -0500 From: "Jacques A. Vidrine" To: Munechika SUMIKAWA Message-ID: <20030416124657.GD72501@madman.celabo.org> References: <200304161121.h3GBLDhJ040405@repoman.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304161121.h3GBLDhJ040405@repoman.freebsd.org> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.3i-ja.1 cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libipsec pfkey_dump.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2003 12:47:00 -0000 On Wed, Apr 16, 2003 at 04:21:13AM -0700, Munechika SUMIKAWA wrote: > sumikawa 2003/04/16 04:21:13 PDT > > FreeBSD src repository > > Modified files: > lib/libipsec pfkey_dump.c > Log: > Make character buffer more bigger. > > Obtained from: KAME > MFC after: 1 week Hmm. - char prefbuf[10]; + char prefbuf[20]; . . . snprintf(prefbuf, sizeof(prefbuf), "/%u", pref); These sizes seem arbitrary. Previously, at 10 bytes, they were just a bit too small to hold the representation of the largest 32-bit unsigned integer. Now at 20 bytes, they are just a bit too small to hold the representation of the largest 64-bit unsigned integer. This seems sloppy. (As does using a 128 byte buffer to hold the result of concatenating two 20 byte buffers.) No big deal, I was just looking to make sure there were no other implications and it struck me as odd. Cheers, -- Jacques A. Vidrine http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se