orcmid has asked for review:
Issue 126635: Possible null pointer dereference
https://bz.apache.org/ooo/show_bug.cgi?id=126635
Attachment 85139: patch to main/sw/source/core/doc/poolfmt.cxx
https://bz.apache.org/ooo/attachment.cgi?id=85139=edit
--- Comment #10 from orcmid ---
Created attachment 85139
--> https://bz.apache.org/ooo/attachment.cgi?id=85139=edit
patch to main/sw/source/core/doc/poolfmt.cxx
This modification removes an incorrect test that never passes and that if it
did pass would cause a null-pointer crash.
In all uses of this helper procedure, the pColl parameter is always the value
of pNewColl as allocated and set in the method SwDoc::GetTxtCollFromPool
pNewColl can never be NULL at the time lcl_SetNumBul is called simply because a
NULL value would have causes a crash earlier in GetTxtCollFromPool. So long as
all allocations by *new* throw exceptions and never return NULL pointers, that
is not possible.
ANALYSIS
The first place that could happen is at line 335, if a NULL pointer is obtained
from a table. Assume that entries to the table are always of pointers returned
from successful *new* operations.
Then the ultimate place that pNewColl could be NULL and crash before
lcl_SetNumBul is ever called is at line 383 with a NULL returned by the *new*
operation at whichever of line 375 or 380 is performed.
By default, failed *new* operations throw an exception and do not return any
value.
There is no need to check pNewColl in GetTxtCollFromPool so long as the *new*
implementation used throws exceptions when an allocation/instantiation fails.
NOTE
The consequences of lcl_SetNumBul never accomplishing anything previously is a
greater concern for the safety of this patch. We need to be satisfied that it
suddenly functioning does not have unintended consequences.
I would like broader review than that which led to the previous patch being
unacceptable.
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org