Closed
Bug 283349
Opened 20 years ago
Closed 20 years ago
Assertion failure: ns->prefix, at jsxml.c:2298
Categories
(Core :: JavaScript Engine, defect, P1)
Tracking
()
VERIFIED
FIXED
mozilla1.8beta2
People
(Reporter: igor, Assigned: brendan)
Details
(Keywords: js1.5, Whiteboard: [have patch])
Attachments
(2 files)
1.14 KB,
patch
|
igor
:
review+
shaver
:
superreview+
|
Details | Diff | Splinter Review |
1.09 KB,
patch
|
Details | Diff | Splinter Review |
The following script:
var x = <x>text</x>;
var ns = new Namespace("http://foo.com/bar");
x.addNamespace(ns);
print(x.toXMLString());
Generates assertion failure when run in js shell built from trunk on 2005-02-23:
js -x ~/s/x.js
Assertion failure: ns->prefix, at jsxml.c:2298
Aborted
Assignee | ||
Comment 1•20 years ago
|
||
Oops, got carried away there -- too many degrees of freedom in E4X on whether a
namespace can have an undefined (null in this impl) prefix, the empty string
(meaning default namespace), or a non-empty string. GetNamespace was ignoring
the undefined (null) case that can arise programmatically via 'ns = new
Namespace; x.addNamespace(ns)'.
In general, qn->prefix can be null or the empty string, too. For a namespace
ns, !ns->prefix means that no prefix was specified, while IS_EMPTY(ns->prefix)
means this is a default namespace. Since qn->prefix is set only by calls to
js_NewXMLQName*(), and some of those pass NULL for prefix while others pass a
variable that came from ns->prefix (which could be the empty string), we have
to test like so:
(!ns->prefix || IS_EMPTY(ns->prefix)) && (!qn->prefix || IS_EMPTY(qn->prefix))
if either ns->prefix or qn->prefix is null, when comparing a namespace's prefix
to a qname's prefix.
Looking for review from igor and shaver, to maximize E4X brainprint.
/be
Attachment #175348 -
Flags: superreview?(shaver)
Attachment #175348 -
Flags: review?(igor)
Assignee | ||
Updated•20 years ago
|
Assignee: general → brendan
Keywords: js1.5
Priority: -- → P1
Whiteboard: [have patch]
Target Milestone: --- → mozilla1.8beta2
Assignee | ||
Updated•20 years ago
|
Status: NEW → ASSIGNED
Reporter | ||
Updated•20 years ago
|
Attachment #175348 -
Flags: review?(igor) → review+
Assignee | ||
Comment 2•20 years ago
|
||
From ECMA-357 13.3.5.4 [[GetNamespace]]:
3. Find a Namespace ns in InScopeNamespaces, such that ns.uri == q.uri. If more
than one such Namespace ns exists, the implementation may choose one of the
matching Namespaces arbitrarily. NOTE: implementations that preserve prefixes in
qualified names may additionally constrain ns, such that ns.prefix == q.[[Prefix]]
That NOTE is less than helpful. As the "Erratum, very tricky, ..." comment just
barely visible in the patch explains, due to how xml-infoset is mapped into e4x,
q.[[Prefix]] for an unprefixed XML tag will be undefined, but we want the
default namespace (prefix == "") to match.
This patch makes the reverse-match work too: an ns with ns.prefix *undefined*
(null in the code) matches a q.[[Prefix]] == "". You won't get an XML node with
[[Name]].[[Prefix]] == "" via the ECMA-357-specified mapping from xml-infoset,
but you could construct such a thing with setName.
Whee! I'm still thinking dark thoughts about E4X distinguishing "no prefix"
from "default namespace prefix (empty string)", but not carrying the logic thru
as required.
/be
Comment 3•20 years ago
|
||
Comment on attachment 175348 [details] [diff] [review]
handle null ns->prefix in GetNamespace
sr=shaver with the IS_EMPTY(ns->prefix ? ns->prefix : qn->prefix)
simplification.
Attachment #175348 -
Flags: superreview?(shaver) → superreview+
Assignee | ||
Comment 4•20 years ago
|
||
Assignee | ||
Updated•20 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment 5•20 years ago
|
||
js/tests/e4x/Regress/regress-283349.js checked in.
Updated•20 years ago
|
Flags: testcase+
You need to log in
before you can comment on or make changes to this bug.
Description
•