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
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
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
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".
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
19 matches
Mail list logo
