search for: size_of

Displaying 9 results from an estimated 9 matches for "size_of".

Did you mean: size_
2019 Jun 11
3
[nbdkit PATCH 0/2] Few rust plugin fixups/nitpicks
There are few more things that could be cleaned up related to the coding style and other things, like explicitly specifying the abi style after "extern" (i.e. `extern "C" fn` instead of `extern fn`), but since those are configurable in rustfmt config, I'm not sure whether the config needs to be added or complying with the defaults should be the priority. But this was just
2008 Nov 12
2
[LLVMdev] Question about SPARC target status
On Nov 11, 2008, at 5:11 PM, Peter Shugalev wrote: > Owen Anderson wrote: >> What about something much simpler: memcpy'ing an array of structs >> around. The number of bytes to be memcpy'd is dependent on the >> padding >> of the struct. > > Anyway, I've got your point. sizeof() constant expression is > calculated > during wrong stage of
2008 Nov 12
0
[LLVMdev] Question about SPARC target status
...llvm won't magically make your C code portable for you. Real portable > languages don't suffer from these problems. I'm not looking for magic, I'm just disappointed that sometimes LLVM turns portable C/C++ code into non-portable one. The workaround is not easy. #define SIZE_OF(T) ((char *)((T*)0 + 1) - (char *)0)) works but it is not constant expression anymore. "Lazy" calculation of sizeof expression would be great though I have to admit it would introduce many complexities to the bytecode including storing and calculation of arbitrary complex constant exp...
2024 Jun 18
1
[PATCH v2 1/8] rust: drm: ioctl: Add DRM ioctl abstraction
...+ // and that the sizeof of the specified type is correct. + $( + let cmd: u32 = $crate::macros::concat_idents!(DRM_IOCTL_, $cmd); + ::core::assert!(i == $crate::ioctl::_IOC_NR(cmd)); + ::core::assert!(core::mem::size_of::<$crate::uapi::$struct>() == + $crate::ioctl::_IOC_SIZE(cmd)); + let i: u32 = i + 1; + )* + }; + + let ioctls = &[$( + $crate::drm::ioctl::internal::drm_ioctl_desc { +...
2019 Aug 16
0
[nbdkit PATCH 2/2] rust: Add support for dynamic .thread_model
...ew (name: *const c_char, open: extern fn (c_int) -> *mut c_void, get_size: extern fn (*mut c_void) -> i64, pread: extern fn (h: *mut c_void, buf: *mut c_char, @@ -122,7 +125,7 @@ impl Plugin { Plugin { _struct_size: mem::size_of::<Plugin>() as u64, _api_version: 2, - _thread_model: thread_model as c_int, + _thread_model: ThreadModel::Parallel as c_int, name: name, longname: std::ptr::null(), version: std::ptr::null(), @@ -159,6 +162,7 @@ impl P...
2019 Aug 16
1
Re: [nbdkit PATCH 2/2] rust: Add support for dynamic .thread_model
...open: extern fn (c_int) -> *mut c_void, > get_size: extern fn (*mut c_void) -> i64, > pread: extern fn (h: *mut c_void, buf: *mut c_char, > @@ -122,7 +125,7 @@ impl Plugin { > Plugin { > _struct_size: mem::size_of::<Plugin>() as u64, > _api_version: 2, > - _thread_model: thread_model as c_int, > + _thread_model: ThreadModel::Parallel as c_int, > name: name, > longname: std::ptr::null(), > version: std::ptr::null...
2019 Aug 16
7
[nbdkit PATCH 0/2] rust: Implement some missing v2 callbacks
Similar to what I just did for OCaml (this IS an API break, requiring recompilation of any existing Rust plugin), and done because I want to add fast_zero support to both languages as part of my upcoming fast zero series. Figuring out how to get extents working was hard enough that I punted that, still. Eric Blake (2): rust: Implement can_cache rust: Add support for dynamic .thread_model
2019 Feb 08
0
[PATCH nbdkit] Add support for writing plugins in Rust.
...n (*mut c_void) -> int64_t, + pread: extern fn (h: *mut c_void, buf: *mut c_char, + count: uint32_t, offset: uint64_t, + flags: uint32_t) -> c_int) -> Plugin { + Plugin { + _struct_size: mem::size_of::<Plugin>() as uint64_t, + _api_version: 2, + _thread_model: thread_model as c_int, + name: name, + longname: std::ptr::null(), + version: std::ptr::null(), + description: std::ptr::null(), + load: None, +...
2019 Feb 08
3
[PATCH nbdkit] Add support for writing plugins in Rust.
This adds very rough support for writing nbdkit plugins in Rust. This is not very idiomatic -- essentially we're handling the direct C calls from nbdkit in Rust. We have to use ‘unsafe’ in a few places because there's no way to tell the Rust code that nbdkit satisfies guarantees (eg. around thread safety, always returning leaked pointers back to the close function, always doing bounds