Skip to main content


Please make sure that you don't use atexit() in a library. Also, while at it, please no exit() or abort(). Thanks! atexit() related issues are insanely troublesome to correct after the use has been introduced. Case point: github.com/openssl/openssl/iss… #development #coding #baddesign
in reply to daniel:// stenberg://

@bagder all assertion failures, stack protector, unhanded exception, etc.

It’s true that abort shouldn’t be called in normal operation but by definition it isn’t normal operation

in reply to Billy O'Neal

@malwareminigun if the library can crash the stack and trigger assertions then that is also a problem
in reply to daniel:// stenberg://

@bagder @malwareminigun C++ exceptions are generally a no-no, since they are not ABI stable.

Also, another thing I generally dislike is using setjmp / longjmp - that is just bad design. Some image decoding libraries seem to think this is a acceptable way doing error handling.

in reply to daniel:// stenberg://

@bagder the point is that calls to abort have to exist. Not that they are desirable in normal operation
in reply to Billy O'Neal

@bagder (I argue that most things that would nominally return EINVAL should be aborts but :shrug:)
in reply to Billy O'Neal

it's not the library's job to abort, that's the application's job
This entry was edited (1 year ago)
in reply to daniel:// stenberg://

@bagder The problem is that often a lot of the context is lost in trying to report that to the application. If app A calls library B calls library C, and C says EINVAL which gets returned by B to A, where the bug is is not clear