A PI name starting with 'xml' is treated as invalid prolog. #2
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
(Automatically imported from issue 2 of the old bug tracker)
Description
Created: 2015-10-27 07:52:40 GMT by Sauli
This PI returns YXML_ESYN error:
<?xml-stylesheet href="mystyle.css" type="text/css"?>
I fixed this in the YXMLS_xmldecl0 state handler, but it may not be the most elegant way to fix it.
Other observations:
Most inline functions like for example yxml_datacontent() have a return type of int when they actually return an enum (yxml_ret_t). My compiler reports this as an error.
The switch statement of the yxml_parse() function has a break in all of the switch cases. However, often the break is unreachable because there is an unconditional return before the break. My compiler gives a warning about these.
Reply 1
Added: 2015-10-27 17:55:03 GMT by Yorhel; Status: new to fixed; Closed: no to yes
Just pushed two commits to fix these issues.
I must have misinterpreted the XML spec when writing the PI-handling code, I even had a test case for an <?xwhatever?> PI that was incorrectly marked as throwing a parse error. The fix I just pushed isn't the cleanest, but... it works. I blame XML for making a strict distinction between the XML declaration and PIs, even though they have the exact same syntax.
As far as I know, this is valid C, and you're not using a conforming compiler if it throws an error (are you using a C++ compiler? That's usually not a good idea with my code as I don't know C++ :). The reason I used ints, however, was because in previous versions I would OR the return values of multiple functions together in some cases. I see that this isn't used anymore, so I changed the return values back to yxml_ret_t.
The downside of autogenerating code is that it doesn't always end up with idiomatic C. In this case the unconditional return comes from a match on 'Char', and the generator doesn't know that will match everything. It's fixable, but I'm not sure it's worth complicating the generator.
Reply 2
Added: 2015-10-28 15:56:37 GMT by Sauli
The compiler is ARM C/C++ (armcc). The error may have something to do with the fact that I use the default compiler options where the compiler is free to use for enum any data type which can hold all the enum values (the smallest possible). Also, the default options don't require strict compliance with the C standard.
Assigning an int to an enum without cast is also not allowed, which is good because then it is not so easy to assign an undefined enum value by mistake. Returning an enum as int would probably have also required a cast - I didn't check and am not going to investigate further.