Hello,
First I did not understand what is wrong to use function or reasons. All
of them are subject to particular "library".
To parse openssl error code in an application code is bad practice.
Richard Levitte wrote:
On Thu, 13 Jun 2019 12:01:46 +0200,
Matt Caswell wrote:
The
additional information you're talking about is something we currently
provide the ERR_add_error_data() function for, and that together with
the reason text (derived from the reason code) is the data the end
user can reasonably get. It's up to whoever writes the error raising
code to provide enough useful information.
Yes, although in practice we don't currently do this (we very rarely add
additional explanatory text). Not sure if that is a problem with the API, our
coding standards, or our culture.
This is partly historical... ERR_add_error_data() has been around
since the beginning of time, and it looks to me like it was designed
in a time where varargs hadn't universally caught on yet (yes, there
was a time before varargs, and it's appropriate to call that "the
stone age").
But developer could format "extra message" for instance :
NSSerr(NSS_F_RSA_SIGN, NSS_R_UNSUPPORTED_NID);
{/*add extra error message data*/
char msgstr[10];
BIO_snprintf(msgstr, sizeof(msgstr), "%d", dtype);
ERR_add_error_data(2, "NID=", msgstr);
}
Another sample is when error message is prepared by third party library:
SSHLDAPerr(SSHLDAP_F_LDAPSEARCH_ITERATOR,
SSHLDAP_R_UNABLE_TO_COUNT_ENTRIES);
...
ret = ldap_parse_result(ld, res, &result, &matcheddn, &errmsg,
NULL, NULL, freeit);
...
if (errmsg) ERR_add_error_data(1, errmsg);
In today's coding practices, I personally find ERR_add_error_data()
clumsy to deal with, so I seldom use it.
There is no reason OpenSSL code to use ERR_add_error_data as usually
library packs whole functionality.
Situation is different when error information if from external sources -
IO, CAPI.
In my cases it could be from NSS, PKCS#11, LDAP.
And so I use this functionality.
Also, being a separate
function, it's easy to forget that it's there and useful. That's a
reason to think that having all integrated in one function call that
includes the flexibility of BIO_printf() probably would encourage
producing better information.
Cheers,
Richard
Roumen
