58967 - xlib + mathml doesn't compile

Status: VERIFIED FIXED

(Core Graveyard :: GFX, defect, P3)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Building with --enable-xlib and --enable-mathml doesn't build.  I'll attach
patches that make it so it does.  I haven't yet gotten xlib to run, so I haven't
been able to test these.  However, I think they should be rather uncontroversial
(correct spelling mistake, and pass the correct arguments to functions).

Blizzard, could you review these?  Or does someone else own xlib these days?

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch to gfx/src/xlib/ (all with #ifdef MOZ_MATHML)

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch to widget/src/xlib/nsWindow.cpp (this probably works on some compilers, but breaks gcc "2.96")

Comment 3

[Christopher Blizzard (:blizzard)]

For the first patch, does (const PRUnichar *)&aString[start] create a temporary
PRUnichar object and leak it?

For the second patch, wouldn't it be better to do something like:

(Window)0 instead of (Window)nsnull?  This is C++ after all.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

> For the first patch, does (const PRUnichar *)&aString[start] create a temporary
> PRUnichar object and leak it?

No, it was just a cast.  But now that you mention it, I'm not sure why it was
there, since I'd think an index into a |const PRUnichar *| would give a |const
PRUnichar|, whose address would then be a |const PRUnichar *|.  But maybe the
last is instead |const PRUnichar * const|, and this was an old-style cast acting
as a const_cast?  If I take it out (it was there before, and it's there in the
GTK code), my compiler (gcc "2.96") doesn't complain, but might others?

Anyway, PRUnichar is just |short int|, and anyway temporary objects created by
implicit construction shouldn't leak.

> For the second patch, wouldn't it be better to do something like:
> (Window)0 instead of (Window)nsnull?  This is C++ after all.

OK, I'll change it.  nsnull is always 0, and I was under the impression Window
was typedef'd to be some pointer type underneath all of it, but perhaps not.
It's an unsigned int.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: new version of patch to widget/src/xlib/nsWindow.cpp

Comment 6

[Christopher Blizzard (:blizzard)]

a=blizzard.  Feel free to check it in.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I think cls just checked in equivalent patches for the MathML changes...

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Remaining patch checked in 2000-12-02 07:56 -0800.

Comment 9

[Chris Petersen]

Marking verified per last comments.