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