These are chat archives for rust-lang/rust

2nd
May 2017
Ingvar Stepanyan
@RReverser
May 02 2017 15:05
FWIW - when it's more convenient, you can as well set crate-type using attribute in the code itself using #![crate_type = "staticlib"]
Aleksey Kladov
@matklad
May 02 2017 15:06
@RReverser doesn't the one in Cargo.toml have higher precedence?
Ingvar Stepanyan
@RReverser
May 02 2017 15:08
not sure, I mean you can just not set it in Cargo.toml and have only in code
kinda convenient when it's a static lib - clearly communicates intent on code level
David Harvey-Macaulay
@alteous
May 02 2017 15:14
Hi, is the correct way of taking the address of the data owned by a Vec<T>? https://is.gd/t4qIKL The context is I need to 4-byte align some data and so I need to determine how many bytes to pad by if necessary.
Ingvar Stepanyan
@RReverser
May 02 2017 15:15
if you need to pad, then maybe you need size and not address?
because start of data is always aligned
(if it was allocated by Vec itself and not with some custom allocator)
David Harvey-Macaulay
@alteous
May 02 2017 15:16
@RReverser What is the start of the data aligned to for a Vec<u8>?
Ingvar Stepanyan
@RReverser
May 02 2017 15:16
.as_ptr() is just pointer to start of that data
what I'm saying is it's already aligned, so I don't understand what you're trying to do
Denis Lisov
@tanriol
May 02 2017 15:17
@alteous Why do you need to align the data?
Frank McSherry
@frankmcsherry
May 02 2017 15:19
@alteous this is what I use:
    // looks like this is often cache-line aligned; yay!
    let addr: usize = unsafe { ::std::mem::transmute(staged.as_ptr()) };
    assert_eq!(addr % 64, 0);
David Harvey-Macaulay
@alteous
May 02 2017 15:20
@RReverser @tanriol Okay, let me explain further. I'm reading some binary data from a file. The layout of the data is determined completely at runtime, and the data is intended to be read sequentially as say [f32; 3] or [u16; 2] or i32 etc. All these types require 4-byte alignment, so I need to guarantee the storage location of the data is 4-byte aligned.
Frank McSherry
@frankmcsherry
May 02 2017 15:20
I think the guarantee is that Vec<T> allocations will be aligned with align<T>(), and if you want 4-byte aligned memory you can grab it either by doing Vec::<u32>::new() or by doing some math on your own with a Vec<u8>.
David Harvey-Macaulay
@alteous
May 02 2017 15:21
I can guarantee that any data read from inside the buffer will be correctly aligned given that the start of the buffer is 4-byte aligned.
Ingvar Stepanyan
@RReverser
May 02 2017 15:21
Any allocated pointer is also guaranteed to be aligned according to your architecture (4 bytes or 8 bytes, still works for your case)
Denis Lisov
@tanriol
May 02 2017 15:21
Are you going to copy the data from the buffer or to use them in-place?
David Harvey-Macaulay
@alteous
May 02 2017 15:22
@RReverser If that's the case then that answers my question and I don't need to stress about this.
Ingvar Stepanyan
@RReverser
May 02 2017 15:23
@alteous you should answer @tanriol's question though just in case. slice from the file is not the same as newly allocated Box / Vec, it obviously won't have such guarantees if you're just transmuting it from any random offset in-place
Denis Lisov
@tanriol
May 02 2017 15:23
@RReverser Are these guarantees documented anywhere?
Ingvar Stepanyan
@RReverser
May 02 2017 15:23
so e.g. if you're trying to read f32 at offset 3 in file - you are out of luck
David Harvey-Macaulay
@alteous
May 02 2017 15:25
@tanriol I guess the data will be copied. At least that's what's happening at the moment with the help of transmute_copy, but this might change in the future.
Ingvar Stepanyan
@RReverser
May 02 2017 15:25

@tanriol for malloc they're documented in libc docs:

The address of a block returned by malloc or realloc in GNU systems is always a multiple of eight (or sixteen on 64-bit systems).

but I'm sure that jemalloc follows the same, need to check their docs too
allocating unaligned data would be very hazardous and could break all sorts of things :)
David Harvey-Macaulay
@alteous
May 02 2017 15:26
@RReverser Yes, but rustc uses jemalloc.
Frank McSherry
@frankmcsherry
May 02 2017 15:26
@alteous unless you are writing a library.
Ingvar Stepanyan
@RReverser
May 02 2017 15:26
@alteous depends on a target

The malloc() function allocates size bytes of uninitialized memory. The allocated space is suitably aligned (after possible pointer coercion) for storage of any type of object.

(c) http://jemalloc.net/jemalloc.3.html

David Harvey-Macaulay
@alteous
May 02 2017 15:27
Here's my current attempt to deal with this: https://github.com/alteous/gltf/blob/tree/src/v2/buffer.rs#L28
Ingvar Stepanyan
@RReverser
May 02 2017 15:27
@alteous I'm sure you don't need to worry about that
David Harvey-Macaulay
@alteous
May 02 2017 15:28
@frankmcsherry @RReverser Ah that's fantastic. Thanks for locating this for me! I guess I have no worries then.
Ingvar Stepanyan
@RReverser
May 02 2017 15:28
you can add debug_assert_eq!(...) just in case, so that you would have assertion that doesn't affect perf of release mode, but I don't think you'll ever hit it unless you're writing custom allocator :)
David Harvey-Macaulay
@alteous
May 02 2017 15:28
I didn't know jemalloc had its own website.
@RReverser That's a good shout, will do.
Ingvar Stepanyan
@RReverser
May 02 2017 15:28
shrug I just googled
David Harvey-Macaulay
@alteous
May 02 2017 15:29
@RReverser Bloody hell, that's embarrassing. Sorry about that. :(
Ingvar Stepanyan
@RReverser
May 02 2017 15:29
it's okay :)
David Harvey-Macaulay
@alteous
May 02 2017 15:29
Okay, thanks for your help all. Have a good day. :)