- Nov 18, 2019
-
-
Yorhel authored
Fixes #5.
-
- Mar 23, 2019
-
-
Yorhel authored
-
- Oct 27, 2015
-
-
Yorhel authored
-
Yorhel authored
Bug #2: http://dev.yorhel.nl/yxml/bug/2
-
- Jul 15, 2015
-
-
Yorhel authored
There is no such thing as YXML_ELEMCLOSE. It's START and END. (Or OPEN and CLOSE, but thats not the terminology I chose to use, apparently).
-
- Feb 26, 2014
- Jan 10, 2014
-
-
Yorhel authored
This reduces the size by a bit over 100 bytes and improves performance a tiny bit.
-
- Dec 05, 2013
- Nov 14, 2013
-
-
Yorhel authored
-
- Nov 13, 2013
-
-
Yorhel authored
-
- Nov 12, 2013
- Oct 14, 2013
- Sep 26, 2013
-
-
Yorhel authored
The start-of-content token (previous use of YXML_CONTENT) had to be returned together with YXML_ELEMSTART in some cases, which resulted in the ugly bitmask hack. The token is not strictly necessary for parsing, and I don't think that it was even that valuable, so its been removed. The YXML_DATA token has been split up into YXML_(CONTENT|PICONTENT|ATTRVAL) to give the application more context as to what kind of data it is receiving. This has the added benefit that the application doesn't need to keep track of whether it is in a context that it doesn't care about (e.g. in a PI) in order to handle data. If the application is interested in element content and not in PIs, then it can now simply ignore the YXML_PI* tokens.
-
Yorhel authored
-
- Sep 25, 2013
-
-
Yorhel authored
Similar reasoning as for allowing non-ASCII characters in data: We can't validate them anyway because yxml operates on bytes and is unaware of the encoding. This does allow a wide range of characters as element/attribute names that aren't formally allowed, but the most common use of those names in applications is simply to check whether a particular element/attribute name matches one that it knows, and unknown names are generally ignored. Without this change, it is impossible to parse "international" XML documents with yxml. It is possible now, but applications do need to do further validation on their own if they want to be conforming.
-
- Sep 24, 2013
-
-
Yorhel authored
-
Yorhel authored
I thought I'd handle the ?-in-PI and ]-in-CDATA problems in a more general solution, but realized that wasn't any simpler or smaller than these specific solutions.
-
Yorhel authored
-
Yorhel authored
-
Yorhel authored
Allowing multiple bytes to be returned in a single YXML_DATA token. This is (unfortunately) necessary for a few special cases: - &#N; for N > 127, - <? ? ?> - <![CDATA[ ] ]]> I'll fix those separately in the next commits. This data string is now also re-used as a temporary buffer for entity/char references, removing the private 'ref' field.
-
- Sep 23, 2013
- Sep 22, 2013
-
-
Yorhel authored
The tests aren't complete yet, there's still a lot of cases that aren't covered.
-
Yorhel authored
-
Yorhel authored
-
Yorhel authored
This avoids complaints from gcc when using a yxml_ret_t variable in a switch statement.
-
Yorhel authored
This code should handle all declarations that don't use a conditional section anywhere.
-
Yorhel authored
-
- Sep 21, 2013
-
-
Yorhel authored
-
Yorhel authored
Previously the misc2 state was entered after the root element has closed, which would still allow for character content and new open tags to be parsed. The latter was already detected with the 'afterelem' trick added in 6bc21882 (now removed again), but that commit did not disallow character content. This also removes the YXML_EMULROOT error code, such errors are now reported as YXML_ESYN. This commit adds ~600 bytes and improves performance for one benchmark and worsens performance for the other. Neither difference is very significant, however.
-
Yorhel authored
-
Yorhel authored
This is a more generic solution, and should ease the implementation of "proper" <!DOCTYPE ..> parsing. (Should I decide to go on with that) This change does not affect performance, and only increases the size with 50 bytes or so.
-