search for: tls_get_error

...83c863e 100644 --- a/src/connections.c +++ b/src/connections.c @@ -602,6 +602,19 @@ validate_request (struct connection *conn, return 1; /* Commands validates. */ } +/* Grab the appropriate error value. + */ +static int +_get_error (void) +{ + int err = errno; + int ret = tls_get_error (); + + if (!ret) + ret = err ? err : EIO; + return ret; +} + /* This is called with the request lock held to actually execute the * request (by calling the plugin). Note that the request fields have * been validated already in 'validate_request' so we don't have to @@ -611,7...

...lake wrote: > +eg. NULL or -1. If the call to C<nbdkit_set_error> is omitted, then > +the value of C<errno> will be used instead. [...] > +/* Grab the appropriate error value. > + */ > +static int > +_get_error (void) > +{ > + int err = errno; > + int ret = tls_get_error (); > + > + if (!ret) > + ret = err ? err : EIO; > + return ret; > +} I don't think we should use the implicit errno. The reason is that we cannot be sure that errno is meaningful in language bindings. A lot of code could run between (eg) a Perl plugin seeing a system cal...

Fix some things I noticed while reviewing v1, and follow Rich's idea to add a new nbdkit_set_error() utility function with a binding for Python users to request a particular error (rather than being forced to live with whatever stale value is in errno after all the intermediate binding glue code). I could not easily find out how to register a C function callable from perl bindings, and have

...the call to C<nbdkit_set_error> is omitted, then >> +the value of C<errno> will be used instead. > [...] >> +/* Grab the appropriate error value. >> + */ >> +static int >> +_get_error (void) >> +{ >> + int err = errno; >> + int ret = tls_get_error (); >> + >> + if (!ret) >> + ret = err ? err : EIO; >> + return ret; >> +} > > I don't think we should use the implicit errno. Pre-patch: C plugins use implicit errno, with reasonable success - but it requires that the C plugins be careful to not corr...

...gin_errno_is_reliable (conn); - if (conn->errno_is_reliable < 0) - r = -1; - else if (!newstyle) + if (!newstyle) r = _negotiate_handshake_oldstyle (conn); else r = _negotiate_handshake_newstyle (conn); @@ -612,7 +609,7 @@ get_error (struct connection *conn) { int ret = tls_get_error (); - if (!ret && conn->errno_is_reliable) + if (!ret && plugin_errno_is_preserved ()) ret = errno; return ret ? ret : EIO; } diff --git a/src/internal.h b/src/internal.h index aa7dbd3..e73edf1 100644 --- a/src/internal.h +++ b/src/internal.h @@ -120,7 +120,6 @@ stru...

See patch 1 for rationale.

This cleans up the existing code base with regards to implicit use of errno from language bindings, then rebases the previous work in python on top of that. I'm still playing with the perl bindings, but got further after reading 'perldoc perlembed'. Eric Blake (4): plugins: Don't use bogus errno from non-C plugins plugins: Add new nbdkit_set_error() utility function python:

...tted, then > >> +the value of C<errno> will be used instead. > > [...] > >> +/* Grab the appropriate error value. > >> + */ > >> +static int > >> +_get_error (void) > >> +{ > >> + int err = errno; > >> + int ret = tls_get_error (); > >> + > >> + if (!ret) > >> + ret = err ? err : EIO; > >> + return ret; > >> +} > > > > I don't think we should use the implicit errno. > > Pre-patch: > > C plugins use implicit errno, with reasonable success - bu...