Re: commit (head): fix 7011

You also added still more 0xffffffff usage which, in some cases (I don't
know about that particular rtf importer code), can be quite corruptive
on 64-bit platforms, causing a lot of the crashes like I'm seeing on my
64-bit box where gdb tells me I segfaulted and, surprise surprise,
someParam=4294967295. Martin has expressed similar discomfort that this
is a very unstable practice. He's hacked certain values to use 0xfffffff
instead, until you'd fix them, but this looks like not-intended
behaviour on any platform. And now I see that you're adding more usage
of 0xffffffff, and it worries me a bit (we are way too close to 2.2.0 to
be _adding_ potentially dangerous behavior). This is from some graphics
code, which apparently never got committed.

        // invalidate stored font allocation number (change of zoom
        // requires font of different size to be loaded into the device
        // context)
+
+ // THIS IS NOT 64-BIT FRIENDLY!
+ // In ILP32, it's -1, in LP64, it's 4294967295.
+ // Use a bloody integer or something! -MG
        m_iFontAllocNo = 0xffffffff;

Even if it isnt a problem in certain cases, I'm not sure it's a habit I
would want to get into. Mainly I'm concerned about potentially reducing
the frequency of crashes in 2.2, and I know that martin also has
expressed alarm/dismay at the use of these values, when we were
investigating a lot of crashes.

Can you please address this (no pun intended)? Or if it isn't unsafe,
satiate my fears by, well, saying so?

Thanks
-MG

On Thu, 2004-08-05 at 06:20, Tomas Frydrych wrote:
> This substantial commit fixes bug 7011, table cells do not merge with
> doc history on. Basically, the problem is that much of the table
> manipulation code queries the piecetable directly for properties and
> attributes, which bypasses the whole revisioning stuff (props and
> attributes in revisioned documents are always function of the view
> and can be substantially different for different simultaneous views
> of the same document). I have modified several PD_Document functions
> to fix this.
>
> This bug touches on a much bigger issue that we will need to look
> into after 2.2, namely clear separation between document and views.
> Layout classes and dialogues should not be able to carry out any
> operations (whether passive or active) on the document, only on the
> view they belong to; document operations should be restricted to the
> view alone. Correspondingly, importers and the document should not be
> allow to do any operations on layout classes, only send notifications
> to the view (for example, at the moment both fl_BlockLayout,
> PD_Document and several importers construct fl_AutoNumber instances).
>
> Tomas
>
> files: number in imp/exp, text/fmt, text/ptbl and wp/ap
>
>
>
Received on Sat Aug 7 20:15:52 2004