Nul charref in element content does not throw error

[Chris Hillery]

The following query:

<elem>&#0;</elem>

should throw XQST0090 because character 0 (NUL) is not legal in XML. However, it succeeds and returns the element with a NUL character in the content. eg, on Linux,

% bin/zorba -f -q /tmp/bar.xq |cat -vet
<?xml version="1.0" encoding="UTF-8"?>$
<elem>^@</elem>

where ^@ is how "cat -vet" displays NUL characters.

This is causing the FOTS case prod-DirElemContent/Constr-cont-charref-2 to fail (or at least it will after the latest FOTS driver changes are merged - currently this bug was being hidden by a different bug).

[Chris Hillery (ceejatec)]

As a note, Zorba *does* throw XQST0090 when &#x0; appears in a single literal:

% bin/zorba -q '"&#x0;"'
<.>:1,2: static error [err:XQST0090]: "Invalid XML v1.0 codepoint in the string literal ""&#x0;""": invalid character reference in XML ; raised at /home/ceej/zo/src/src/compiler/api/compiler_api.cpp:201

[Chris Hillery (ceejatec)]

Luis - this is totally outside your areas of expertise, I realize, but would you mind taking a crack at it anyway? Might help you learn a bit about some other parts of Zorba.

[Luis Rodriguez Gonzalez (kuraru)]

Just as a pointer, after checking the code generated by Flex, we found a function that we initially thought should manage the problem we are currently have, there is a function called checkXmlRefs, the problem is that the test case that is included in the defect never touches that code, Chris found that this code is only executed for StringLiteral token but not in the case where the charref is enclosed in an element, so my guest is that there should be a way to mnodiy the Grammar rules so checkXmlRefs gets call in that case too. Also the same problem happens when the nul-charref is included as a Attribute so I assume the solution should be similar to this one.