On 04/01/2011 01:33 PM, marius zbihlei wrote:
On 04/01/2011 12:53 PM, Timo Teräs wrote:
Yes. My argument was that it absolutely does not work in two cases:
- the memory allocated for the string is exactly the strings length (you'd be overwriting random places with the string terminator)
- the same memory area is used for two overlapping strings: changing one byte would change all string references using that area
Though, in this instance the second item does not seem possible. I'm not sure if the first item can happen or not.
Well, I think the first case is what happens. it will not overwrite random places, it will place a \0 at the end of the allocated buffer(even the memory location is not part of that buffer). Because buffer[length] points to some memory in pkg memory pool, accessing it will not cause an access violation (it's not an address in .txt or .ro segments) . The only problem I forsee is that during the set of \0 and the revert to the original value, the address location would be accessed in some other way, but I doubt it (keep in mind that locations have to be properly aligned - so i presume in most cases a padding byte will be overwritten). Not a good practice, but if no bugs are present I don't recommend changing it.
What if that byte is actually pkg memory pool management data? That breaks memory allocation which is done when doing deep copy?
But yes, the re.subst fix alone seems to have removed all the valgrind reported issues.
- Timo