[BUG] Tag File Parsing Issue
Robert Abel <[email protected]> Sun, 18 Mar 2012 02:10:27 +0100
| Newsgroups | gmane.text.doxygen.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi,
I'm currently using tag files to stitch multiple documentation files
(for multiple programming languages) together.
There seem to be two bugs related to tag/xml files:
1. Tag files are statically produced with encoding='ISO-8859-1'
(doxygen.cpp ll.10604).
Yet there is not one instance of a conversion function used that I
could find that would actually convert any tag file output from the
source input file encoding given using INPUT_ENCODING. That doesn't
seem right!
2. There is a bug in tagreader.cpp. Basically, QXmlSimpleReader
(qxml.cpp) will read any XML input file according to its encoding
stated in each file. However, the TagFileParser handler in
tagreader.cpp will store all incoming QString (16bit) strings inside
m_curString which is a QCString (8bit) inside bool characters
(tagreader.cpp ll. 789).
This effectively annihilates the correctly parsed XML source
encoding when curString is assigned to different information
entities, e.g. when assigning group titles in ll. 664. While I'm not
100% sure what happens at this implicit conversion, I reckon the
QString will be using the thread locale to convert the QCString back
to 16bit, thus resulting in gibberish when thread locale and XML
encoding mismatch.
As a quick fix for 2.), I changed the declaration of m_curString to
QString so no conversions take place (but there may be memory overhead
wrt explicit/implicit sharing I read?). I didn't notice any immediate
problems with this hack.
As a fix for 1.) I propose to either actually convert to ISO-8859-1 from
the INPUT_ENCODING, or just declare the XML file to be encoded using
INPUT_ENCODING. The latter would be simplest and cleanest, IMHO.
Also, please notice that 2.) cannot just be fixed by fixing 1.), since
tag files might be produced by "3rd party" software using any encoding
they wish. The quick and dirty fix for 2.) I did would probably need
some revisitation by someone who knows about the memory overhead/sharing
capabilities involved and can decide on a proper course of action.
(Which is why I'm hesitant to post a [one-line] patch...)
Regards
Robert Abel
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Doxygen-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/doxygen-develop