From owner-p4-projects@FreeBSD.ORG Fri May 30 09:22:15 2003 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id D3D9637B404; Fri, 30 May 2003 09:22:14 -0700 (PDT) Delivered-To: perforce@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63B6B37B401 for ; Fri, 30 May 2003 09:22:14 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BDD943F85 for ; Fri, 30 May 2003 09:22:13 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9/8.12.9) with ESMTP id h4UGLIOn031639; Fri, 30 May 2003 12:21:18 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)h4UGLIqu031636; Fri, 30 May 2003 12:21:18 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Fri, 30 May 2003 12:21:18 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Adam Migus In-Reply-To: <3ED75FBF.2080302@migus.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: perforce@freebsd.org Subject: Re: PERFORCE change 32072 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2003 16:22:15 -0000 On Fri, 30 May 2003, Adam Migus wrote: > Ok, so let left = the maximum string length constant you defined, > instead of size with the original code. Do the math at the end to > calculate any discrepancy. The problem's solved, the snprintf() > semantics are preserved and your original fix is again redundant. As long as you're slapping down a '\0' inside the string, you'll have to deal with two lengths: the actual string length, and the desired string length--you can't dereference to the desired length, but you also can't return the desired length. In the overflow length, the '\0' handling can be dropped, since it generates an error condition and there's no expectation that the string be nul-terminated, so one simplification would be drop the nul termination rewrite entirely in the overflow case. That said, I think we're still dealing with an API robustness problem: this coding error was easy to make because snprintf() and the C string interfaces aren't robust in the presence of failures. They encourage coding faults. Moving to sbuf in the long term will help with that substantially. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories