Subject: Re: More on select all - paste bug.
From: Mike Nordell (tamlin@algonet.se)
Date: Sun Nov 19 2000 - 16:00:32 CST
Martin Sevior wrote:
> I didn't fix this after all. Further investigation leads me to think that
> our pieceTable is being corrupted on large pastes.
[explanation how to reproduce this showstopper]
Check fl_DocSectionLayout::deleteOwnedPage().
Sure, its m_pFooterSL is separated from zero, too bad it's 8 (yes eigth).
Pretty bad shit, no. This one is called from fp_Page d'tor, and apparently
we can't even trust that one, or...
> Somone with a clue:
>
> If a function is defined:
> PD_Document::getAppProps(*) const
[...]
> How can I call a function that changes a member variable within
> getAppProps?
Language legally you can only do it if that member variable is defined
"mutable" (like a caching data member). If that's not it, the interface or
your intentions are wrong. I'd go for "mutable" first and then look at
redesigning the bad interface.
What I suggest is that we *now* introduce two extra UT_ functions:
UT_BOOL UT_IsAddressReadable(const void* p, size_t len);
UT_BOOL UT_IsAddressWritable(void* p, size_t len);
I don't know if these would have catched this one any earlier, but they sure
would contribute to the quality of AW. They would be left up to the
implementation of any OS layer, and for those not supporting memory
protection they would simpy return UT_TRUE.
Now a question to the ones criticising Purify (like "it nags when there is
no problem"):
Have you ever used it when there *is* a problem?
Don't cc, I'll get back to the list about my findings.
/Mike
This archive was generated by hypermail 2b25 : Sun Nov 19 2000 - 16:00:41 CST