WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
11815
XPathEvaluator behavior does not match Firefox - substring() and empty element
https://bugs.webkit.org/show_bug.cgi?id=11815
Summary
XPathEvaluator behavior does not match Firefox - substring() and empty element
Jesse Costello-Good
Reported
2006-12-12 14:43:45 PST
The following test cases do not behave the same in Safari as in Firefox.
Attachments
proposed fix
(4.06 KB, patch)
2007-01-28 02:11 PST
,
Alexey Proskuryakov
darin
: review+
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Jesse Costello-Good
Comment 1
2006-12-12 14:45:55 PST
// #1: // An empty node value causes the substring() function to return true when it should return false. var strXML = '<data><record id="-a-"></record><record id="a-a">-hi-</record></data>'; var doc = (new DOMParser()).parseFromString(strXML, "text/xml"); var xpe = new XPathEvaluator(); var objResult = xpe.evaluate("//record[substring(.,1,1)='-']", doc, null, 0, null); var itm = null; var objNodes = []; while (itm = objResult.iterateNext()) objNodes.push(itm); assertEquals(1, objNodes.length); // Safari yields 2
Jesse Costello-Good
Comment 2
2006-12-12 14:47:04 PST
// #2 // function name() does not work with attribute nodes var strXML = '<data><record id="-a-" a="v">???</record><record id="a-a">{abc}</record></data>'; var doc = (new DOMParser()).parseFromString(strXML, "text/xml"); var xpe = new XPathEvaluator(); var objResult = xpe.evaluate("//@*[name()='id']", doc, null, 0, null); var itm = null; var objNodes = []; while (itm = objResult.iterateNext()) objNodes.push(itm); assertEquals(2, objNodes.length); // Safari yields 0
Jesse Costello-Good
Comment 3
2007-01-19 22:32:29 PST
I split this out in to two different issues. #2 is moved to
bug 12340
.
Alexey Proskuryakov
Comment 4
2007-01-27 13:03:23 PST
This appears to be a general problem in our XPath code - all C++ string literals are treated as boolean values. Easy to fix by adding another constructor to XPath::Value, but I cannot understand how this occurs; suspecting a gcc bug. Please tell me I'm wrong :-). Test case: ----------------------- #include <stdio.h> class String { public: String(const char*) {} }; class Value { public: Value(bool) { printf("bool\n"); } Value(const String&) { printf("String\n"); } }; int main() { Value val(""); } -----------------------
David Kilzer (:ddkilzer)
Comment 5
2007-01-27 15:06:40 PST
(In reply to
comment #4
)
> This appears to be a general problem in our XPath code - all C++ string > literals are treated as boolean values. > > Easy to fix by adding another constructor to XPath::Value, but I cannot > understand how this occurs; suspecting a gcc bug. Please tell me I'm wrong :-).
I believe this Google Groups thread answers it:
http://groups.google.com/group/comp.lang.c++/browse_thread/thread/73ab483d2ef241c/487423eb73ee10d6%23487423eb73ee10d6
Alexey Proskuryakov
Comment 6
2007-01-28 01:38:29 PST
The replies in this thread point out that pointers can be converted to bool - but a string literal is not a pointer, it's "const char[n]" (with a deprecated conversion allowing it to be converted to char*). OTOH, the two transformations needed to get from a string literal to a bool fall into different categories (lvalue transformation and conversion), and are thus allowed in a standard conversion sequence, see section 13.3.3.1 of the standard. Not that I can claim complete understanding now, but I'm convinced.
Alexey Proskuryakov
Comment 7
2007-01-28 02:11:17 PST
Created
attachment 12721
[details]
proposed fix
Darin Adler
Comment 8
2007-01-28 18:06:15 PST
Comment on
attachment 12721
[details]
proposed fix r=me
Alexey Proskuryakov
Comment 9
2007-01-29 10:01:16 PST
Committed revision 19225.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug