#Padding, Pointers

55 messages · Page 1 of 1 (latest)

burnt cloud
#

Assume a 64-bit sysytem.
why -8

image.png
turbid lightBOT
#

When your question is answered use !solved to mark the question as resolved.

Remember to ask specific questions, provide necessary details, and reduce your question to its simplest form. For tips on how to ask a good question use !howto ask.

#

@burnt cloud

Screenshots!

Your message appears to contain screenshots but no code. Please send code and error messages in text instead of screenshots if applicable!

fresh lantern
#

sizeof a pointer

#

also im pretty sure thats undefined behavior

burnt cloud
#

what could be the reason to substract sizeof a pointer

fresh lantern
#

the int is being padded

burnt cloud
#

example usage

image.png
#

so when we set it to e - 8 , it goes 8 bytes back int_32t data is 4 bytes we have 4 bytes padding and the remaining e?

fresh lantern
#

the grey area is the padding

burnt cloud
#

thanks alot!!

#

!solved

turbid lightBOT
#

Thank you and let us know if you have any more questions!

This thread is now set to auto-hide after an hour of inactivity

lofty oak
#

i'm new here - isn't it dangerous to assume that there will be padding?

fresh lantern
#

yes

#

he said its a

Assume a 64-bit sysytem.
so yeah you can expect it to be a multiple of 8

#

however its still ub

vast thistle
#

would be better to use some sort of offsetof if you're going to be trying to do this, you're probably safe as long as the pointer you get at the end is actually a real thing

burnt cloud
#

this is an exam question from operating systems lecture, focuses on padding, original code was e - 4 we neeeded to correct that

lofty oak
#

i don't think it's a fair question

fresh lantern
#

the struct padding should be defined by the ABI

#

so it should be fine as long as you follow what the ABI expects/does

lofty oak
#

where can i check that?

vast thistle
vast thistle
#

if you know alignment

#

since every object has to be aligned, you always have to pad up to that alignment

#

you can't start an 8 byte aligned object at a 4 byte offset

lofty oak
#

i'm aware that it makes sense, but the correct answer still has to begin with: " assuming that each field is aligned to 8 bytes"

vast thistle
#

well

#

tbf it doesn't say assume you have alignment

#

but im not aware of a case in c where this alignment doesn't happen

#

I think c even specifies that things have to be at minimum the alignment of the size

#

and since its 64 bit, and this is a pointer, that pointer is 8 bytes and has 8 byte alignment

lofty oak
#

this wouldn't make sense because you have attribute packed

vast thistle
#

I sure dont

#

thats attribute is basically telling the compiler to ignore normal c alignment

#

and is non-standard afaik

fresh lantern
#

somewhere you find a table of all C values

#

and there will be a column with alignment

lofty oak
#

it says that int is aligned to 4 🤷‍♂️

fresh lantern
#

sure

#

but the struct also contains a pointer

#

and its alignment is a multiple of 8

vast thistle
#

since the object contains a pointer the natural alignment of the obejct its going to be 8
therefore if the int is first it starts at an alignment of 8
then we go by 4, so now we are aligned by 4 still, but we are half way through our 8 alignment block
so then you have to pad by 4 to reach the next 8 and then can start to pointer

# 
|a|a|a|a| | | | |b|b|b|b|b|b|b|b| 
^       ^       ^       ^       ^
0       4       8       12      16
#

you can't move the pointer up because it would have to have an alignment of 4

#

which it doesn't

#

this is why its important to consider the order of your members

# 
struct A {
  int i;
  int* j;
  int k
};
```in most x64 abis is size 24 and has 8 bytes of padding
```c
struct B {
  int i;
  int k
  int* j;
};
```in most x64 abis is size 16 and has 0 bytes of padding
#

in a world where cache-misses are so significant switching from A to B could cause a dramatic performance improvement