On 5 Jun 2001 [EMAIL PROTECTED] wrote:
> As discussed on [EMAIL PROTECTED] - add a comment about the assert/checking
> input debate. Our policy is "don't check input values." Feel free
> to change the wording. It's something, but we've had two longish
> threads in the last day about this...
Doh, you beat me to it. Gotta love that "up-to-date check failed"
commit error. =-) Anyway, this looks fine to me. I was going to take
more of a list-ified approach (I admit it, I'm a listaholic), something
like this:
<P>
We also have very high expectations for code quality, and to us this
means following these otherwise-undocumented coding policies:
<UL>
<LI>Avoid the use of excessive static buffers
<LI>Use the memory pool mechanism to ensure proper cleanup
<LI>Write thread-safe code
<LI>We expect one or two levels of optimizations to be applied: Is a
bitmask faster for this? Is a strchr() faster than an index()? Etc.
<LI>Parameter checking is generally unnecessary (we prefer for the
code to segfault in these cases as it makes for easier debugging)
<LI>Assertions are not needed in fatal conditions that would result in
an
immediate segfault anyway
<LI>...
</UL>
This list is not an exclusive one; it'd be nice if all of the group's
policies were documented, but they're not yet. We'll add them here as
they come up.
</P>
But I'm perfectly fine with leaving the way you've done it. Thanks.
--Cliff
--------------------------------------------------------------
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
