Assert in applications is *very* different from assert in an OS. Assert in an application is supposed to be "this shouldn't ever happen, but since I am paranoid, do this". It is frequently (always?) built as a macro so that it can be compiled out. In an OS, (or, really, in any library), this is not necessarily favorable behavior. Would you, as an app writer, want your app to *stop* if the library writer has a bug? Really hard to tell. It might be a bug that would cause the application to do Bad Things (like send packets to the wrong address or broadcast them or something). OTOH, stopping is a good thing for debugging the library - it prevents applications from working so that a bug can be reported. We debated this for quite a while in Glass Elevator, under the guise of exceptions. Asserts are really primitive exceptions for C. I guess my take on it would be that user input (app writer input, for us) should *NEVER* cause an assertion. No combination of calls, no API interfacing should cause an assertion. That is what error return codes are for. Assertions should be reserved for "I am internally screwed up in some way". As an example. Let's say you had a linked list. Attempting to add a NULL pointer to it should not cause an assertion. If the linked list realized that it had become circular (this happened to me - it was a multi-threaded issue), that should throw an assertion. The list didn't lock itself properly, in my case. This is just MHO. I am open to better ideas on this... And thanks, Scott, for bringing it up... > >