Selon Caolán McNamara <caol...@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.
realloc_patch_3.patch
Description: Binary data
realloc_patch_4.patch
Description: Binary data
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
