On 6/7/23 12:00, Richard W.M. Jones wrote: > On Tue, May 30, 2023 at 05:48:25PM +0200, Laszlo Ersek wrote: >> BTW I'm foreseeing a problem: if the extended block descriptor can >> provide an unsigned 64-bit length, we're going to have trouble exposing >> that in OCaml, because OCaml only has signed 64-bit integers. So that's >> going to reproduce the same issue, only for OCaml callers of the *new* API. >> >> I can see Eric's series includes patches like "ocaml: Add example for >> 64-bit extents" -- I've not looked at those yet; for now I'm just >> wondering what tricks we might need in the bindings generator. The >> method seen in the "middle patch" above won't work; we don't have a >> native OCaml "i128" type for example that we could use as an escape >> hatch, for representing C's uint64_t. > > I think that's OK because disk sizes are already limited to > 2^63 - 1 by the kernel (and for qemu even less than that). > The OCaml bindings return a (signed) int64 for NBD.get_size.
Under patch#7 yesterday, I made a proposal for "armoring" at least one instance / direction of the uint64_t <-> int64 conversion. It raised an interesting problem: raising OCaml exceptions in such C functions that are *not* directly called by the OCaml runtime. Comments would be much appreciated in that subthread! (On a tangent: I've also noticed we use CAMLparam0() & friends in some of our functions that are *not* directly called by the OCaml runtime. They certainly run on the OCaml runtime's stack, but there's at least one intervening stack frame where the C-language function is provided by us. Now I know we must use CAMLparam0() in our *outermost* such function, but what about the further functions (inner C-language functions) that our outermost function calls in turn? I think the inner functions are at liberty not to use CAMLparam0() -- otherwise, our functions couldn't even call normal C library functions!) Thanks, Laszlo
