gcc calloc behavior when allocating memory to void* - c++

Question

i know this is not a good way to use void pointers, but i am curious about this behavior.
int main()
{
void* ptr;
void* next;
ptr = ::operator new(8);
next = (void*)((char*)ptr + 1) ;
*(int*)next = 90;
*(int*)ptr =100;
cout << "Ptr = " << ptr<<endl;
cout << "Ptr-> " << *(int*)ptr<<endl;
cout << "Next = " << next<<endl;
cout << "Next-> " << *(int*)next<<endl;
}
---------------
Result :
Ptr = 0x234e010
Ptr-> 100
Next = 0x234e011
Next-> 0
---------------
in both 64bit(x86_64) and 32bit(x86) platforms (Linux and windows) when add more than 4 byte to ptr, 90 will remain in where next is pointing to, but when add less than 4,
*next suddenly became 0 when *ptr=100 will be execute, same result with calloc and malloc
Why changing the content of where ptr point have to change the content of where ptr+1 point ? and why this not ganna happen when we go more than 4 byte ? and if it is about memory alignment why same behavior on both 32bit and 64bit platforms ?
also same result in delphi (windows 32bit/Embarcadero)
Thank you and sorry for my bad English

Answer 1

As you're on an X86 architecture, alignment won't be a problem: the processor can access unaligned memory, even if it's slower.
Intel processors store data with the least significant byte FIRST. Google about endianness to get a more in-depth explanation. What happens is
vvvvvvvvvvvvvvvv this is Ptr
+===+===+===+===+===+===+===+===+
| |100| 0 | 0 | 0 | | | |
+===+===+===+===+===+===+===+===+
^^^^^^^^^^^^^^^^ this is next after you say '*next=100'
now when you store 90 to *Ptr, this changes to
vvvvvvvvvvvvvvvv this is Ptr
+===+===+===+===+===+===+===+===+
| 90| 0 | 0 | 0 | 0 | | | |
+===+===+===+===+===+===+===+===+
^^^^^^^^^^^^^^^^ this is next
so next becomes 0, because its first 3 bytes get overwritten by 0, and the last byte is 0 anyways.

Answer 2

ints are (typically) 4 bytes. You're only adding one byte to ptr for next rather than 4. This means that ptr and next overlap, thus your assignment of 100 is clobbering the last byte of 90 (which happens to 0 it out).
You need:
next = (void*)((char*)ptr + sizeof(int));
And really you need to just use properly typed pointers.

Answer 3

What appears to be happening is that the eight bytes of memory have the following contents after each operation:
*(int*)next = 90; // 90 == 0x00 00 00 5A
--> 0x?? 5A 00 00 00 ?? ?? ??
*(int*)ptr = 100; // 100 == 0x00 00 00 64
--> 0x64 00 00 00 00 ?? ?? ??
As a result, *(int*)next is now equal to zero. Note that you can't count on this behavior, since it depends on the underlying hardware.

Answer 4

This is nothing to do with allocation or void* and everything to do with your making assumptions about how values are stored in memory.
You wrote an int, a unit occupying 4 bytes on your system, to address 101 and then wrote another to address 100, overwriting 3 of the first value.
Unfortunatelty, the system you used doesn't use the endianess/byte ordering you assumed whereby the lsb of the first value would occupy address 104. The result was that one of the four zero bytes from your second write made the first value zero.
This is because you invoked undefined behavior using char offsets to bit twiddle int values.
When ints become 8 bytes anyone who was using their own hand manipulation of pointers will have the same problem.
Incidentally, you should be able to tell form this something about the word order of your systems numeric representation.