Selon Caolán McNamara <caolanm@redhat.com>:
2. The other possible solution is to take advantage that in this case I can see that the string is bring shrunk, so (double-checking man realloc) on failure "the original block is left untouched". Right before the realloc a NULL char is entered at the point where the programmer wants to shrink the string to. So the string is already truncated, the programmer just want to try and free the now unused space. On fail of realloc pFullQualified is left alone and that truncated original string will already give the right results, albeit with a tiny extra memory overhead, so... char *pTmp; pFullQualifiedName[nLengthOfHostName] = '\0'; pTmp = realloc(pFullQualifiedName, nLengthOfHostName + 1); if (pTmp) pFullQualifiedName = pTmp; Would be good too, seeing as we know we're attempting to free the unused part of the string that lies after the inserted NULL terminator.And in "ure/sal/osl/w32/security.c"
In this case I guess the only thing that can be done on realloc failure is to return from this with sal_False to indicate failure (after doing the same free of the original pre-realloc buffer. That'll cascade into a bit of a ugly and tiring free everything else that's malloced and un-freed just before that return. Its painful to handle these things completely in C, C++ is easier to manage them with std::vector or scoped pointers. C.
Hi, I guessed that too. I was just wondering if freeing some bytes was worth while. A patch for this... Regards.
Attachment:
realloc_patch_3.patch
Description: Binary data
Attachment:
realloc_patch_4.patch
Description: Binary data