1 Apr
2011
1 Apr
'11
6:33 a.m.
On 04/01/2011 12:53 PM, Timo Teräs wrote:
On 04/01/2011 11:17 AM, marius zbihlei wrote:
static buffers are not nice solution and can break depending on the call
chain. However, since if it's going to be deep copied anyway, it'll
probably work here. I was not sure about the deep copying part, so I
hesitated to suggest it as possible fix.
Hello,
I pushed the patch to master and 3.1.
Yes, I tried this actually earlier right after sending my previous mail.
It seems that this cured all the remaining valgrind errors I was seeing.
So yes, this should definitely pushed to all applicable git repos/branches.
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.
Cheers,
Marius