Rapid Xml parse error if you don't use strlen (or similar function) on a
download?
Hello fellow code monkeys,
I've run into the oddest problem I've ever seen today. I'm using a
codebase that uses rapidXml (unmodified to my knowledge). (C++ code base)
If I download a file (using proprietary code but that we've used for many
years) leaving it in the buffer, and then parse it with rapid xml, I get
back a parse error at the base tag. I've walked through the code and
satisfied myself to seeing that something is messed up.
If I download the file in Chrome, I can open the file, and validate the
XML easily. I can also download the file, open it with my program using
basic file commands and parse it into the rapidXML that way, and that
works.
If I open the file, and download the file at the same time with my program
the files strncmp perfectly. There is a trailing null on the file IO, but
adding that to download doesn't fix anything.
But this is where the query is.
If I strncmp and then parse the download buffer with rapid XML, the parse
completes correctly. If I do the same but instead run strlen, and then
parse the buffer, it also completes correctly.
It's not a time issue, as the download phase is finished, and I can open
the file and parse that, after the download, but before parsing the
downloaded buffer, and I'll still parse the download buffer incorrectly.
So the question is, I know strlen is a non destructive operation, it
actually shouldn't even change any of the data. It does return back the
shorter file size (by a byte) as expected. However is there any idea what
strlen (or strncmp) can be doing that causes the system to correctly parse
the buffer correctly?
Some factoids if necessary, the files are currently 141k, the download is
off of a storage cloud that's reliable, and my code does not operate until
the download is finished, and that code has stopped running, strlen and
strncmp is the standard variants, non destructive operations.
No comments:
Post a Comment