Removing function names from errors (PR 9058)

[Roumen Petrov]

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