Re: Removing function names from errors (PR 9058)

2019-06-14 Thread Richard Levitte
On Fri, 14 Jun 2019 07:13:21 +0200, Viktor Dukhovni wrote: > > #define ERR_raise_error ERR_raise_error_internal(__FILE__, __LINE__, > > __FUNC__) > > Well, __FUNC__ is entirely non-standard, and __func__ is C99. Are > we ready to abandon C89/C90? If not, then __func__ (and variants) > becomes

Re: Removing function names from errors (PR 9058)

2019-06-13 Thread Viktor Dukhovni
On Fri, Jun 14, 2019 at 01:41:51PM +1000, Dr Paul Dale wrote: > I’m behind ditching the function identifier #defines but not their text names. Good to hear. > #define ERR_raise_error ERR_raise_error_internal(__FILE__, __LINE__, __FUNC__) Well, __FUNC__ is entirely non-standard, and __func__ is

Re: Removing function names from errors (PR 9058)

2019-06-13 Thread Dr Paul Dale
I’m behind ditching the function identifier #defines but not their text names. The varargs based error function seems like a good idea too. It would be nicer if the ERR_raise_error function included the file and line information without them needing to be specified. As an exercise for the

Re: Removing function names from errors (PR 9058)

2019-06-13 Thread Viktor Dukhovni
On Wed, Jun 12, 2019 at 05:51:44AM +0200, Richard Levitte wrote: > 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: > >

Re: Removing function names from errors (PR 9058)

2019-06-13 Thread Richard Levitte
On Thu, 13 Jun 2019 22:04:17 +0200, Roumen Petrov wrote: > > Richard Levitte wrote: > > On Thu, 13 Jun 2019 20:23:05 +0200, > > Roumen Petrov wrote: > >> Hello, > >> > >> First I did not understand what is wrong to use function or > >> reasons. All of them are subject to particular "library". >

Re: Removing function names from errors (PR 9058)

2019-06-13 Thread Roumen Petrov
Richard Levitte wrote: On Thu, 13 Jun 2019 20:23:05 +0200, Roumen Petrov wrote: Hello, First I did not understand what is wrong to use function or reasons. All of them are subject to particular "library". We didn't say anything against reason codes. As a matter of fact, I do find those

Re: Removing function names from errors (PR 9058)

2019-06-13 Thread Richard Levitte
On Thu, 13 Jun 2019 20:23:05 +0200, Roumen Petrov wrote: > > Hello, > > First I did not understand what is wrong to use function or > reasons. All of them are subject to particular "library". We didn't say anything against reason codes. As a matter of fact, I do find those useful. Function

Re: Removing function names from errors (PR 9058)

2019-06-13 Thread Matthew Lindner
Hi I'm a developer that writes code that interfaces with OpenSSL. One perspective I think that is missing that I haven't seen is that error codes that point to the exact point in the OpenSSL code that caused an issue are often needed to debug code that interfaces with OpenSSL. Importantly because

Re: Removing function names from errors (PR 9058)

2019-06-13 Thread 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

Re: Removing function names from errors (PR 9058)

2019-06-13 Thread Salz, Rich
>So basically, what you're actually saying is that we should add additional errors up the call stack... so if some function called OPENSSL_zalloc(), it should be perfectly OK to raise a ERR_R_MALLOC_FAILURE, but functions above should *add* things like

Re: Removing function names from errors (PR 9058)

2019-06-13 Thread Roumen Petrov
Hi Viktor, Viktor Dukhovni wrote: On Wed, Jun 12, 2019 at 10:02:25AM +0100, Matt Caswell wrote: OTOH I do find them quite helpful from a debugging perspective, e.g. when people send in questions along the lines of "I got this error what does it mean/how do I fix it" - although what is

Re: Removing function names from errors (PR 9058)

2019-06-13 Thread Richard Levitte
On Thu, 13 Jun 2019 18:26:41 +0200, Salz, Rich wrote: > > >The proper way to handle this, in my experience, is *DO NOT REUSE ERROR > > CODES.* Each error code appears in exactly one place, and we could > > eventually build up documentation explaining what they mean, the causes, > > and how

Re: Removing function names from errors (PR 9058)

2019-06-13 Thread Salz, Rich
>The proper way to handle this, in my experience, is *DO NOT REUSE ERROR > CODES.* Each error code appears in exactly one place, and we could eventually > build up documentation explaining what they mean, the causes, and how to > address this. This means, we don't use ERR_R_MALLOC when

Re: Removing function names from errors (PR 9058)

2019-06-13 Thread Tomas Mraz
On Thu, 2019-06-13 at 19:34 +1000, Tim Hudson wrote: > On Thu, Jun 13, 2019 at 6:40 PM Salz, Rich wrote: > > The proper way to handle this, in my experience, is *DO NOT REUSE > > ERROR CODES.* > > No. This is a path to a rather unacceptable outcome. > Taking your example and running forward

Re: Removing function names from errors (PR 9058)

2019-06-13 Thread Richard Levitte
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

Re: Removing function names from errors (PR 9058)

2019-06-13 Thread Matt Caswell
On 13/06/2019 10:50, Richard Levitte wrote: > > Good point, but note that there is no conflict with what I wrote. Yes, I realise that. > The > additional information you're talking about is something we currently > provide the ERR_add_error_data() function for, and that together with > the

Re: Removing function names from errors (PR 9058)

2019-06-13 Thread Richard Levitte
On Thu, 13 Jun 2019 11:16:38 +0200, Matt Caswell wrote: > > I agree with everything Richard just said. I just have some additional > thoughts > inserted below. > > On 13/06/2019 10:00, Richard Levitte wrote: > > If we look at it from the perspective of the application author, > > what's most

Re: Removing function names from errors (PR 9058)

2019-06-13 Thread Tim Hudson
On Thu, Jun 13, 2019 at 6:40 PM Salz, Rich wrote: > The proper way to handle this, in my experience, is *DO NOT REUSE ERROR > CODES.* 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

Re: Removing function names from errors (PR 9058)

2019-06-13 Thread Matt Caswell
I agree with everything Richard just said. I just have some additional thoughts inserted below. On 13/06/2019 10:00, Richard Levitte wrote: > 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

Re: Removing function names from errors (PR 9058)

2019-06-13 Thread Richard Levitte
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

Re: Removing function names from errors (PR 9058)

2019-06-13 Thread Salz, Rich
I think exposing the function internals is a mistake for a couple of reasons: it encourages familiarity with, and dependence on, OpenSSL library internals, and it goes against the spirit of layering, and there is no guarantee that the function code does not change as internal code gets moved

Re: Removing function names from errors (PR 9058)

2019-06-12 Thread Viktor Dukhovni
On Wed, Jun 12, 2019 at 10:02:25AM +0100, Matt Caswell wrote: > OTOH I do find them quite helpful from a debugging perspective, e.g. when > people > send in questions along the lines of "I got this error what does it mean/how > do > I fix it" - although what is actually useful is usually the

Re: Removing function names from errors (PR 9058)

2019-06-12 Thread Roumen Petrov
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. There is a lot of situation where application logs debug information. Adding

Re: Removing function names from errors (PR 9058)

2019-06-12 Thread Matt Caswell
On 12/06/2019 04:51, 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

Removing function names from errors (PR 9058)

2019-06-11 Thread Richard Levitte
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