search for: size_of

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

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

...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...

...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...

...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...

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

...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, +...

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