PERFORCE change 32072 for review

[Adam Migus]

<quote who="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

Ok, so add another int and you can track both lengths.
 Why do you want to use sbufs sighting failures when
you said you stress tested the code for three hours
and could not make it fail with your redundant fix
present?
This is getting old.  I think this code is fine but I
don't work on the MAC framework (and wish I never had)
so if you wanna replace it using sbufs, assembly code,
or COBOL be my guest, I could care less.

-- 
Adam Migus - Research Scientist
Network Associates Laboratories (http://www.nailabs.com)


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