search for: renumer

For now, there is no change to the generated code (although the man pages are slightly improved), but this will make it easier for later patches to improve OCaml and Golang bindings so that set/get pairs are typed symmetrically. --- generator/API.ml | 16 ++++++++++------ generator/API.mli | 2 ++ generator/C.ml | 20 ++++++++++++-------- generator/GoLang.ml | 13 ++++++++++++-

Natural fallout after my recent testsuite additions that fixed a couple of ocaml bugs in the setters. However, on at least the OCaml code, I'm not sure what we should do if a newer libnbd ever returns a bit that an older NBD.mli was not expecting at the time the OCaml compiler ran (see below). I'm also not sure if there is a more efficient way to avoid outputting Val_FOO() converters for

Now that we have a distinct branch in the generator when returning an enum or bitmask that cannot fail, we can use it in OCaml for symmetry, so that the result of a get function can be plugged into a set function without manual conversion of an integer. This includes the use of the recently-added UNKNOWN catch-all for encoding C values returned by a newer libnbd.so than when the OCaml bindings

On Sat, Sep 05, 2020 at 08:40:58PM -0500, Eric Blake wrote: > diff --git a/generator/API.mli b/generator/API.mli > index 712e837..e45b5c0 100644 > --- a/generator/API.mli > +++ b/generator/API.mli > @@ -78,6 +78,8 @@ and ret = > | RString (** return a newly allocated string, > caller frees, NULL for error *) > | RUInt

Now that we have a distinct branch in the generator when returning an enum or bitmask that cannot fail, we can use it in Golang for symmetry, so that the result of a get function can be plugged into a set function without a trip through other types. --- generator/GoLang.ml | 12 ++++++------ .../libnbd/libnbd_110_defaults_test.go | 6 +++---

Now that we have a distinct branch in the generator when returning an enum or bitmask that cannot fail, we can use it in OCaml for symmetry, so that the result of a get function can be plugged into a set function without manual conversion of an integer. While at it, add an abort() if OCaml ever hands us a value we can't translate to a C int (that one is unreachable per OCaml type safety), or

On 9/7/20 9:13 AM, Richard W.M. Jones wrote: >> +++ b/generator/C.ml >> @@ -66,15 +66,15 @@ let errcode_of_ret = >> function >> | RBool | RErr | RFd | RInt | RInt64 | RCookie -> Some "-1" >> | RStaticString | RString -> Some "NULL" >> - | RUInt -> None (* errors not possible *) >> + | RUInt | REnum (_) | RFlags

On Mon, Sep 07, 2020 at 09:38:15AM -0500, Eric Blake wrote: > On 9/7/20 9:13 AM, Richard W.M. Jones wrote: > > >>+++ b/generator/C.ml > >>@@ -66,15 +66,15 @@ let errcode_of_ret = > >> function > >> | RBool | RErr | RFd | RInt | RInt64 | RCookie -> Some "-1" > >> | RStaticString | RString -> Some "NULL" >

Well, the golang changes (patch 1 and 2/3 of v1) were already committed, all that was left was the OCaml changes. I'm a lot happier with how things turned out with an UNKNOWN constructor in the OCaml variants. Eric Blake (3): tests: Enhance coverage of enum/flag range checking ocaml: Support unknown values for Enum/Flags ocaml: Typesafe returns for REnum/RFlags generator/OCaml.ml

On Sat, Sep 05, 2020 at 08:40:57PM -0500, Eric Blake wrote: > Natural fallout after my recent testsuite additions that fixed a > couple of ocaml bugs in the setters. However, on at least the OCaml > code, I'm not sure what we should do if a newer libnbd ever returns a > bit that an older NBD.mli was not expecting at the time the OCaml > compiler ran (see below). I'm also

Right now, libnbd has refused to issue a command not advertised as supported by a server, mainly because the NBD protocol does not guarantee what the server will do, and libnbd would rather stay in sync with the server than drop the connection. However, for integration purposes, it can be handy to coerce libnbd into sending something to see how the server will react (whether it be an extension

In v2: - now based on my proposal to add LIBNBD_SHUTDOWN_IMMEDIATE - four flags instead of two: STRICT_FLAGS is new (patch 4), and STRICT_BOUNDS is separate from STRICT_ZERO_SIZE (patch 5) - various refactorings for more shared code and less duplication Eric Blake (5): api: Add xxx_MASK constant for each Flags type generator: Refactor filtering of accepted OFlags api: Add