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 reader, I’ll skip any implementation details but will note that it is possible without using variadic macros. Pauli Hint: #define ERR_raise_error ERR_raise_error_internal(__FILE__, __LINE__, __FUNC__) int (*)(int, const char *, ...) ERR_raise_error_internal(const char *, int, const char *); -- Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia > On 14 Jun 2019, at 12:04 pm, Viktor Dukhovni <openssl-us...@dukhovni.org> > wrote: > > 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: >> >> SYSerr(SYS_F_FSTAT, errno); >> >> (incidently, there's another PR, 9072, which changes those to >> 'SYSerr("fstat", errno)') >> >> So, the main points of discussion seem to be: >> >> - should we remove function indicators in our error reporting? >> - should we make an exception for system errors (SYSerr())? > > Bottom line, my take is that function indicators should stay, but > string names would be more convenient all around than numeric codes. > > -- > Viktor.