Removing function names from errors (PR 9058)

Tomas Mraz tmraz at
Thu Jun 13 11:01:02 UTC 2019

On Thu, 2019-06-13 at 19:34 +1000, Tim Hudson wrote:
> On Thu, Jun 13, 2019 at 6:40 PM Salz, Rich <rsalz at> wrote:
> > The proper way to handle this, in my experience, is *DO NOT REUSE
> No. This is a path to a rather unacceptable outcome. 
> Taking your example and running forward with it, having an out-of-
> memory separate error code for every possible context would like to
> 589 error codes for just handling out-of-memory in master at a single
> level.
> And then on top of that you would need to cascade those errors up the
> call chain potentially.
> Each error condition that might require different treatment should
> have a common code.
> The concept of out-of-memory (as a simple example) is not context
> specific (in terms of handling).
> The concept of unable-to-open-file is also not context specific.

Exactly, as application writer I do not really care about whether the
out of memory condition happened when creating some particular part of
RSA key or when allocating memory to store the RSA key der
representation or whatever.

In case of opening a file, it would be much more useful (by the use of
additional error data) to know which file name failed to open.

Also the debugging information for the library writers should be
attached automatically but of course must be separated from the
information useful to the end user.

Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your

More information about the openssl-project mailing list