There's already a taint system in place, but you can't really use it for return codes. Even if we were to do something like this, there is no straightforward way to enforce checking of the return code in a timely manner. The best you could really do is check the next time the API is called, which could be too late. One could instrument the code, but that's hardly worth the effort. I'm going to keep repeating that the API needs to be simple enough that people will actually use it. Therefore, we're not going to add unnecessary parameters, force people to check return values, or anything like that. People are going to get reasonable behavior by default, and it will be possible to change the behavior when desired. For example, you could easily use a callback mechanism to mimic errno, and then check that after each call (have a per-thread errno value if you're using a threaded application). John On Tuesday, February 11, 2003, at 02:01 PM, Kim Reece 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. > > Perhaps an acknowledgement system of some type? ie. having parameters > for > "die" or "don't die" or "die if they don't check it", then a function > the > user of the library would call to say "return code checked, > acknowledge so > I can use the results". Basically a taint system. > > It wouldn't take a very large modification, but I don't know how well > it > would fit into the paradigm you're going for. > > --Sorel >
This archive was generated by hypermail 2b30 : Wed Feb 12 2003 - 09:20:50 PST