The discussion so far has touched on a number of items that aren't necessarily the same thing:
- the instability of function codes. - debugging information - display of errors and then, the point that no one talks about but that's the main reason error codes in general exist at all: - an application's need to figure out what went wrong and how to react The current error codes have these items added together: - library code (I'll touch on that further down) - function code (debugging information) - reason code If we look at it from the perspective of the application author, what's most often needed are reliable error/reason codes (to check and to react appropriatly to) and associated reason strings (for display). For the application author, it would normally be completely uninteresting exactly which function the error happened in (think about it, when's the last time you wanted to know exactly which internal function in libc raised the EAGAIN you just got?). For the application author, the interesting bit is usually "what went wrong?" (reason) and "what did I call?" (they already know that). If we look at *our* needs as library writers, then the exact location that raised the error is interesting, of course! But then, is it interesting in the form of codes, or are we rather interested in the text form? I dunno about you, but I don't give a damn about the actual library and function codes, I look at the displayed library names and function names. (and yet, they aren't necessarily enough without knowing the OpenSSL version). Finally, if we look at it from a provider author's perspective, dealing with all these different codes is quite hard. Ideally, a provider author should just need to deal with their own reason codes and associated strings, and that's about it. What I would like to see is a simplified error system that delivers reason codes, and attached extra text information. That text information could have two parts, where one is debugging information (__FILE__, __LINE__, __FUNC__, and possibly exact commit hash generated with 'git archive', see "export-subst" in gitattributes(5)), and the other is the extra data added with the likes of ERR_add_error_data(). We certainly already have the infrastructure to allow this, the modifications needed wouldn't be that big. On the subject of 'openssl errstr', it's abssolutely fine for errors raised within our libraries, but outside of that, it's useless. This is an issue with engines that no one has spoken about but that has been there all along. See, engines, if they use our error reporting system at all, usually allocate a new library code dynamically, by calling ERR_get_next_error_library(). Since the library code may differ from one time to the next, the complete error codes raised will differ, giving 'openssl errstr' an impossible job, even if the engine is loaded. This issue is exactly the same for provider modules. This makes library codes less than useful outside of our libraries. I digress.. the main point is, however, that we need to keep the application author's needs from our needs. That affects how we look at error codes. Cheers, Richard On Wed, 12 Jun 2019 05:51:44 +0200, Richard Levitte wrote: > > Many of us, both past and present, have looked at the error reporting > code and wante to change it somehow. There's currently a PR, 9058, > which covers one aspect, the function name indicator. > > A -1 was raised early on for the purpose of starting a discussion, and > eventually (possibly?) a vote. > > A discussion point in that PR is whether it's still interesting to > keep information on the system function/callback that was called when > we're reporting a system error, i.e. this type of error report: > > SYSerr(SYS_F_FSTAT, errno); > > (incidently, there's another PR, 9072, which changes those to > 'SYSerr("fstat", errno)') > > So, the main points of discussion seem to be: > > - should we remove function indicators in our error reporting? > - should we make an exception for system errors (SYSerr())? > > Cheers, > Richard > > P.S. I'm personally not entirely sure that we need an actual vote, if > this discussion shows that we all agree. Perhaps to confirm and make > the decision formally solid? > > -- > Richard Levitte levi...@openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/