Bug 11815 - XPathEvaluator behavior does not match Firefox - substring() and empty element
Summary: XPathEvaluator behavior does not match Firefox - substring() and empty element
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: XML (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Alexey Proskuryakov
URL:
Keywords:
Depends on:
Blocks: 10489
  Show dependency treegraph
 
Reported: 2006-12-12 14:43 PST by Jesse Costello-Good
Modified: 2007-01-29 10:17 PST (History)
2 users (show)

See Also:


Attachments
proposed fix (4.06 KB, patch)
2007-01-28 02:11 PST, Alexey Proskuryakov
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Costello-Good 2006-12-12 14:43:45 PST
The following test cases do not behave the same in Safari as in Firefox.
Comment 1 Jesse Costello-Good 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
Comment 2 Jesse Costello-Good 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

Comment 3 Jesse Costello-Good 2007-01-19 22:32:29 PST
I split this out in to two different issues. #2 is moved to bug 12340.
Comment 4 Alexey Proskuryakov 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("");
}
-----------------------
Comment 5 David Kilzer (:ddkilzer) 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

Comment 6 Alexey Proskuryakov 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.
Comment 7 Alexey Proskuryakov 2007-01-28 02:11:17 PST
Created attachment 12721 [details]
proposed fix
Comment 8 Darin Adler 2007-01-28 18:06:15 PST
Comment on attachment 12721 [details]
proposed fix

r=me
Comment 9 Alexey Proskuryakov 2007-01-29 10:01:16 PST
Committed revision 19225.