Dynamic array ot not

[Ali Çehreli]

On 1/16/22 17:51, H. S. Teoh wrote:

 >> In practice, malloc'ed memory is cleared e.g. by memset(). Or, there is
 >> calloc() which returns memory filled with zeros.
 >
 > Correction: malloc() is not guaranteed to clear the allocated memory.

Agreed. What I meant is, the programmer ordinarily clears it with memset().

 >> I didn't know free wrote into the freed buffer but since it's
 >> undefined behavior, we shouldn't even be able to know whether it did
 >> or not. :/
 > [...]
 >
 > This is likely caused by the implementation of malloc/free. Some
 > implementations store pointers and other tracking information inside the
 > free blocks themselves

Yes but they do not (and cannot) put it inside what they returned. They 
store such information in the area right before the returned pointer.

 > Some memory allocator implementations may also store a canary value at
 > the beginning of freed blocks to detect double free's

I thought of that as well but I doubt they would go against the 
mentioned performance ideals.

My current theory is that our writeln() calls after the free needed 
memory for the output strings and it got the last freed memory. 
(Assuming a common implementation of a free list where the next 
allocated memory is the one most recently freed.) Well... speculation... :)

 > unlikely to occur in user data that, if detected by free()

Yes, those are human-identifiable as well but I don't think it's related 
in this case because they look random values. (Speculation: A string's 
.ptr value. :) )

Ali