Egbert Eich

For me, this issue is resolved by the fix for bug 26. Check my comment there.

For me, this issue is resolved by the fix for bug 26. Check my comment there.

The proposed patch also resolves the issues reported in bug 16 and bug 20. This exposes a general weakness of this parser: it assumes that the XML passed is well formed to a certain extent and doesn't have thorough checking. strcspn() (and strspn()) are used in many more places throughout the code and exhibit the same problem: if the requested condition cannot be met anywhere in the string, these function stop at the /0 terminating the string. This condition is never checked and acted upon as this...

The proposed patch addresses the issue demonstrated by the attached test case. All said in this comment applies.

The proposed patch addresses the issue demonstrated by the attached test case. All said in this comment applies.

The proposed patch addresses the demonstrated by the attached test case. All said in this comment applies.

This bug, just like bug 22 and bug 23 takes advantage of the fact, that ezxml assumes that (re)allocation of memory will always succeed. There are many more cases where this can be exploited. It seems that this project was chosen as a test case for a tool written for the purpose of testing whether software handles (re)allocation failures properly. The issue demonstrated by the attached test case can be mitigated by the attached patch. This begs the question how useful this patch is as it only addresses...

This segfault arises by not properly verifying if there is still data left to read after normalizing line endings. The proposed patch addresses this.