On Tuesday 08 of January 2013, Michael Meeks wrote:
> On Tue, 2013-01-08 at 05:19 -0800, julien2412 wrote:
> > Hello Michael,
> >
> > Reading this thread, I took a look at sal/rtl/source/strtmpl.cxx
> > 969 static IMPL_RTL_STRINGDATA* IMPL_RTL_STRINGNAME( ImplAlloc )(
> > sal_Int32 nLen )
>
> .
On 01/08/2013 02:19 PM, julien2412 wrote:
Reading this thread, I took a look at sal/rtl/source/strtmpl.cxx
969 static IMPL_RTL_STRINGDATA* IMPL_RTL_STRINGNAME( ImplAlloc )(
sal_Int32 nLen )
970 {
971 IMPL_RTL_STRINGDATA * pData
972 = (sal::static_int_cast< sal_uInt
On Tue, 2013-01-08 at 05:19 -0800, julien2412 wrote:
> Hello Michael,
>
> Reading this thread, I took a look at sal/rtl/source/strtmpl.cxx
> 969 static IMPL_RTL_STRINGDATA* IMPL_RTL_STRINGNAME( ImplAlloc )(
> sal_Int32 nLen )
...
> Since we cast "nLen" parameter in "sal_uInt32", could it help
ut nLen should be >= 0 ?
Of course, we don't expect a length to be negative but perhaps this function
is called with a negative value in very specific cases.
(advantage of the assert, it costs nothing in non debug)
Julien
--
View this message in context:
http://nabble.documentfoundation.
On Thu, 2013-01-03 at 19:44 +0200, Noel Grandin wrote:
> We could throw a StringAllocationFailed exception, and catch it near
> the bottom if the import process, and use that to indicate that the
> document is corrupt.
Sigh - this brings us back to the old chestnut of the impact exception
On Thursday 03 of January 2013, Markus Mohrhard wrote:
> 2013/1/3 Lubos Lunak :
> > On Thursday 03 of January 2013, Markus Mohrhard wrote:
> >> Hey,
> >>
> >> while going through the list of calc documents crashing during import
> >> I came across gnome#627420-1.ods which creates an insanely large
2013/1/3 Noel Grandin :
> We could throw a StringAllocationFailed exception, and catch it near the
> bottom if the import process, and use that to indicate that the document is
> corrupt.
>
The document is not corrupt. IT is perfectly fine, the problem is
either in our import code, which just miss
2013/1/3 Lubos Lunak :
> On Thursday 03 of January 2013, Markus Mohrhard wrote:
>> Hey,
>>
>> while going through the list of calc documents crashing during import
>> I came across gnome#627420-1.ods which creates an insanely large
>> OUStringBuffer that ultimately leads to a crash. Since I believe
We could throw a StringAllocationFailed exception, and catch it near the
bottom if the import process, and use that to indicate that the document is
corrupt.
On Thursday, 3 January 2013, Lubos Lunak wrote:
> On Thursday 03 of January 2013, Markus Mohrhard wrote:
> > Hey,
> >
> > while going throu
On Thursday 03 of January 2013, Markus Mohrhard wrote:
> Hey,
>
> while going through the list of calc documents crashing during import
> I came across gnome#627420-1.ods which creates an insanely large
> OUStringBuffer that ultimately leads to a crash. Since I believe we
> have quite a few places
10 matches
Mail list logo
