If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

xlib + mathml doesn't compile

VERIFIED FIXED in mozilla0.9

Status

Core Graveyard
GFX
P3
normal
VERIFIED FIXED
17 years ago
9 years ago

People

(Reporter: dbaron, Assigned: dbaron)

Tracking

Trunk
mozilla0.9
x86
Linux

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Assignee)

Description

17 years ago
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?
(Assignee)

Comment 1

17 years ago
Created attachment 18609 [details] [diff] [review]
patch to gfx/src/xlib/ (all with #ifdef MOZ_MATHML)
(Assignee)

Comment 2

17 years ago
Created attachment 18611 [details] [diff] [review]
patch to widget/src/xlib/nsWindow.cpp (this probably works on some compilers, but breaks gcc "2.96")
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.
(Assignee)

Comment 4

17 years ago
> 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.
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
(Assignee)

Comment 5

17 years ago
Created attachment 18720 [details] [diff] [review]
new version of patch to widget/src/xlib/nsWindow.cpp
a=blizzard.  Feel free to check it in.
(Assignee)

Comment 7

17 years ago
I think cls just checked in equivalent patches for the MathML changes...
(Assignee)

Comment 8

17 years ago
Remaining patch checked in 2000-12-02 07:56 -0800.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 9

17 years ago
Marking verified per last comments.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.