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 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.
>
> Incidently, I did mention thinking about a new (better, I hope) error
> raising function on github, and might as well repeat it here:
>
> int ERR_raise_error(int reason, const char *fmt, ...);
>
> To allow for debugging information (like I mentioned, some sensible
> combination of __FILE__, __LINE__, __FUNC__, and possibly git commit
> id), one might imagine this:
>
> int ERR_add_debug_info(const char *file, size_t line,
> const char *func, const char *commitid);
>
> or a combo of both:
>
> int ERR_raise_error_debug(int reason,
> const char *file, size_t line,
> const char *func, const char *commitid,
> const char *fmt, ...);
>
> Note that this doesn't have to conflict with the current error raising
> code, all we need to do is to convert whatever input ERR_put_error()
> gets into the new form.
I think this is quite a good idea. One possible concern is an exponential growth
the amount of string data that we have. Not sure what impact that might have on
the size of the library.
Matt
