PERFORCE change 32072 for review

[Robert Watson]

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 at fledge.watson.org      Network Associates Laboratories

To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-cvs" in the body of the message