Why is the address of a second variable not right after the first variable?

Question

I am aware that on a 64-bit system, a Vec will store an 8-byte pointer to the heap, 8 bytes for the capacity and 8 bytes for the length.

I assume that the address of a is right after the address of v, but when I checked the boundaries of the vector allocation on the stack, I found it always occupies 31 bytes of stack memory, 7 bytes more than it should. This goes the same for strings.

pub fn main() {
    let v = vec![1_u8];
    let a = 1_u8;

    let v_raw = &v as *const _;
    let a_raw = &a as *const _;

    println!("v addr = {:p}, dec = {}", v_raw, v_raw as usize);
    println!("a addr = {:p}, dec = {}", a_raw, a_raw as usize);
    println!("offset = {} bytes", a_raw as usize - v_raw as usize);

    // changing below 3 print will affect the mysterious 7 bytes
    //    println!("v_raw addr = {:p}", &v_raw);     // (1)
    //    println!("a_raw addr = {:p}", &a_raw);     // (2)
    println!("v as_ptr = {:p}", v.as_ptr()); // (3)

    // dereference through offset 24 to 30 -> 7 bytes
    let mut offset = 24_usize;
    loop {
        if offset == 31 {
            break;
        }

        // usize to *const usize(raw pointer)
        let mut addr = (v_raw as usize + offset) as *const usize;
        let deref_value = unsafe { *addr as u8 };

        println!(
            "offset = {}, addr = {:p}, value hex = {:x}, value = {}",
            offset, addr, deref_value, deref_value
        );

        offset += 1;
    }
}

v addr = 0x7fffbcf48b70, dec = 140736363531120
a addr = 0x7fffbcf48b8f, dec = 140736363531151
offset = 31 bytes
v as_ptr = 0x55d9c823ea40
offset = 24, addr = 0x7fffbcf48b88, value hex = 0, value = 0
offset = 25, addr = 0x7fffbcf48b89, value hex = 0, value = 0
offset = 26, addr = 0x7fffbcf48b8a, value hex = 0, value = 0
offset = 27, addr = 0x7fffbcf48b8b, value hex = 0, value = 0
offset = 28, addr = 0x7fffbcf48b8c, value hex = 0, value = 0
offset = 29, addr = 0x7fffbcf48b8d, value hex = 0, value = 0
offset = 30, addr = 0x7fffbcf48b8e, value hex = 0, value = 0

Sometimes these 7 extra addresses contains all 0 values, and sometimes not if I uncomment all the println! macros marked (1)(2)(3)

As I declared v and a in sequence, I was expecting that a is next to v on the stack, so why do I get these 7 bytes extra? Is this extra memory designed for something special?

i'm assuming the address of `a` is right after the address of `v` on stack but there are always 7 address in between — liyanchao, Jul 10 '19 at 15:04
because I tried with other types and they are always consecutively on stack and tried with vector and string and its always 7 bytes more, i just wanted to know what are these 7 bytes for. — liyanchao, Jul 10 '19 at 15:20

Peter Hall · Accepted Answer · 2019-07-10T16:10:52.947

2

I assume that the address of a is right after the address of v.

Just because you wrote these variables in this order does not mean that Rust will store them consecutively on the stack. The Rust compiler is free to place things in memory wherever it sees fit, and you absolutely cannot rely on the ordering. The final ordering could be different depending on:

the version of the Rust compiler
if you are compiling for debug or release
the target operating system
the target CPU architecture
other code nearby in your application

The actual size of the Vec can be shown to be 24:

let v = vec![1_u8];
println!("size = {}", std::mem::size_of_val(&v)); // size = 24

See also:

Why do subsequent Rust variables increment the stack pointer instead of decrementing it?

edited Jul 10 '19 at 16:10

answered Jul 10 '19 at 15:11

Peter Hall

53,120
14
139
204

Do you think "alignment" is covered well by "target CPU architecture" or should it be specifically called out? – Shepmaster Jul 10 '19 at 15:19
@Shepmaster it is covered in the linked question. It perhaps could have been a dupe actually... – Peter Hall Jul 10 '19 at 15:28
[You have the power](https://media1.tenor.com/images/fb248007bce02deafaf54fe62565421a/tenor.gif) – Shepmaster Jul 10 '19 at 15:41
what i am actually wondering is that is rust always assign 31 bytes for vector/string on stack or 24 and the extra 7 we can ignore, thanks – liyanchao Jul 10 '19 at 15:48
1

@liyanchao It's 24. The other bytes you are talking about could be any fragment of the other code in the function, including the expanded `println` macros, inlined functions or anything else. – Peter Hall Jul 10 '19 at 16:28
1

It looks to me like the 7 "extra" bytes are for padding the `u8` in your example, and have nothing to do with the `Vec` at all. Although in reality they are probably not "extra" bytes but would be used for more local variables if you had any. – trent Jul 10 '19 at 16:30
1

@liyanchao Put another way, the stack frames probably have to be aligned to 8 bytes because of the ABI. In this case you have 25 bytes worth of stack data, so it takes 32 bytes worth of stack. The compiler just decided to put the 7 padding bytes between `v` and `a`. – trent Jul 10 '19 at 16:38
i tried this many times on 2 different computers and its always 7 so i thought maybe compiler is doing something secretly :D now i can finally move on, thanks guys – liyanchao Jul 10 '19 at 17:04

Why is the address of a second variable not right after the first variable?

1 Answers1