Date: Fri, 30 May 2003 12:21:18 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Adam Migus <amigus@migus.org> Cc: perforce@freebsd.org Subject: Re: PERFORCE change 32072 for review Message-ID: <Pine.NEB.3.96L.1030530120010.27495A-100000@fledge.watson.org> In-Reply-To: <3ED75FBF.2080302@migus.org>
index | next in thread | previous in thread | raw e-mail
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 Laboratorieshelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1030530120010.27495A-100000>