On Thu, 2011-03-03 at 02:22 -0700, Tor Lillqvist wrote:
for a cherry-pick candidate to libreoffice-3-3. It's a very simple &
safe fix, and fixes a crasher as reported in
But do you know how those values can end up being negative in the
first place, is that a symptom of something being horribly wrong
otherwise, and this patch now then just plasters over that and instead
of crashing it might permit silent data corruption elsewhere then
instead?
Good point. I wondered about the same thing.
I didn't exactly look into why they (actually only one of them) ended up
negative, but from the logic of the code those values should never be
negative anyway as they represent the size of something & are used to
allocate arrays to their size. So, even if I knew the reason for the
negative value & fixed it, I would still test for those negative values
(and they are signed integers, not unsigned).
Also, the possibility of silent data loss is unlikely, since this code
provides data for individual tick marks that are automatically
generated, and they are not stored with the document but are generated
from the min, max, and interval data (which are stored with the
document).
So, we should definitely look into why the negative value occurs in the
first place, but this change is still necessary regardless of the
outcome.
Kohei
--
Kohei Yoshida, LibreOffice hacker, Calc
<kyoshida@novell.com>
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.