Sun 10 Nov 2013 09:34:41 PM UTC, comment #4:
I stand corrected. I saw in the Linux man page for realloc(3) that calling it with length == 0 would require to free() and thought this was actually required by the standard. But I don't find that in the standard, so probably I was wrong there.
About my claim concerning destroyed free list, I stand corrected as well. The free list is not destroyed immediately, but:
* cp1 and fp1 point to ptr-sizeof(size_t)
* cp and fp2 point to ptr + len, which is ptr if len == 0
* This makes fp1->nx and fp2->sz sharing the same address (ptr) [*]
* the fp2 part is added as a new entry to the free list, leaving the old memory block having a length field of 0 and nothing else, even no space for a ->nx pointer.
This does not hurt until I call free(ptr), ptr being the value just returned from realloc(). There the fact [*] above makes it impossible to add the now being freed part, which is uncapable to hold a nx pointer, to the free list, as the said fp2->sz is now tampered as well.No matter if that part of memory is still free or allocated in the meanwhile, this leads to trouble sooner or later.
This fact makes this bug a duplicate of bug #32702, which AFAICS already contains a test case and which I would consider as rather severe and important in turn.
Additionally, I'd like to write a test case proving that the bug is destructive if realloc() is called with a new length of < sizeof((struct __freelist).nx) if that is necessary. But that may take some days, as I first would have to wrap my head around making the test cases work in my build environment. Maybe I get the opportunity in the next days to do so.
Again, sorry for the noise made by contradicting myself, and for sounding quite vague, but nevertheless I hope that I could contribute and/or help concerning that bug #32702.
|