mirror of
https://github.com/Zenithsiz/ftmemsim-valgrind.git
synced 2026-02-04 02:18:37 +00:00
776c38e30b
There is a difference between the outputs when using 32bit and 64bit with clang++/libc++ Running the test in a shell with the output piped through c++filt I see 64bit: --2153-- operator new[](unsigned long)(32) = 0x55AB040 --2153-- malloc(31) = 0x55AB0A0 --2153-- operator new[](unsigned long)(8) = 0x55AB100 --2153-- operator new(unsigned long)(16) = 0x55AB150 --2153-- operator new(unsigned long)(16) = 0x55AB1A0 --2153-- operator new(unsigned long)(32) = 0x55AB1F0 --2153-- operator new(unsigned long)(32) = 0x55AB250 32bit: --55024-- operator new[](unsigned int)(28) = 0x7D41030 --55024-- malloc(31) = 0x7D41090 --55024-- operator new[](unsigned int)(4) = 0x7D410F0 --55024-- operator new(unsigned int)(8) = 0x7D41140 --55024-- operator new(unsigned int)(8) = 0x7D41190 --55024-- operator new(unsigned int)(16) = 0x7D411E0 --55024-- operator new(unsigned int)(16) = 0x7D41230 --55024-- operator new(unsigned int)(32) = 0x7D41280 Note the extra 32 byte allocation at the end. This is because of str2 += " rocks (str2)\n"; // interior ptr. at the end of void doit(void) Details of the mechaism here https://stackoverflow.com/questions/21694302/what-are-the-mechanics-of-short-string-optimization-in-libc str2 starts containing 9 characters "Valgrind" Catenating to it makes it "Valgrind rocks (str2)\n" which is exactly 22 characters. The 64bit SSO has a capacity of 22 chars, so there is no need to switch from SSO in the stack variable to using heap allocation. The 32bit SSO only has a capacity of 10, so there there is space in the SSO for the initial string but the catenation expands it beyond the SSO capacity and there is a heap allocation via the std::basic_string allocator, which calls raw ::operator new.