I do know what you're getting at. Let me clarify a bit. There are plenty of places where the library does return an error code, and it is the user's responsibility to check for the correct functionality of their application. I do want to allow such things where possible, as long the API isn't complicated. It's not practical in the slightest to attempt to validate that the programmer is checking the condition. The easiest thing to do along those lines is to check if the programmer explicitly announces he checked it, which you can't do until the next time the program calls into your API, at which point it may very well be too late. In the current library, we do tend to exit the program any time there's the chance of a security issue, more as a placeholder than anything. But, many of those exits from the program can and will go away. For example, consider the case of double freeing a string. This can potentially be a security problem with standard strings. With our library, we detect that you're trying to free a safestr object that has already been freed, so we can just return an error, but instead we exit. We *could* just return from the free with an error code, which is fine. However, for the time being, we don't, and I don't feel bad about it, because if you've got a double-free error, you really should fix your problem! In general, as long as the library can defuse the problem (which is almost always the case), then you can take the following approach: 1) If there's a callback, call it (possibly returning if the callback doesn't abort; the callback can do nothing). 2) Return an error code if the callback returns. The problem is that the API needs to remain simple for people to use it. So having to add parameters for passing back an error code is likely not to be acceptable, particularly for frequently used calls. John On Tuesday, February 11, 2003, at 01:37 PM, Dana Epp wrote: > Instead of simply dieing... is it possible to validate that the > programmer > is checking the error condition? (I don't have an answer to that > myself.) I > would hate to see movement to a safer string library that actually > REMOVES > the ability for developers to build clean failure code paths to allow > for > recovery. I hope you see what I am trying to get at.
This archive was generated by hypermail 2b30 : Tue Feb 11 2003 - 11:59:22 PST