[jira] Created: (XERCESC-1731) Open file failed on MIPS because chForwardSlash in wrong byte-order

Open file failed on MIPS because chForwardSlash in wrong byte-order
-------------------------------------------------------------------

                 Key: XERCESC-1731
                 URL: https://issues.apache.org/jira/browse/XERCESC-1731
             Project: Xerces-C++
          Issue Type: Bug
          Components: Utilities
    Affects Versions: 2.7.0
         Environment: MIPS
Linux 2.6.16
GNU iconv
            Reporter: Yunhai Zhang
            Priority: Critical


We try to migrate some code to MIPS paltform, and got a failer while parsing an xml file using xerces-c++.
So we check the code and found that when a LocalFileInputSource is constructed, the file name is composed as following:
        XMLString::copyString(fullDir, curDir);
        fullDir[curDirLen] = chForwardSlash;
        XMLString::copyString(&fullDir[curDirLen+1], filePath);

and chForwardSlash is define as following:        
        const XMLCh chForwardSlash          = 0x2F;

In our MIPS platform, this variant is in big-endian, but curDir and filePath are in little-endian, so we got a wrong fullDir.
The reason why curDir and filePath are in little-endian is that IconvGNUTranscoder only use little-endian transecoder:
static const IconvGNUEncoding    gIconvGNUEncodings[] = {
    { "UCS-2LE",        2,    LITTLE_ENDIAN },
    { "ucs-2-internal",        2,    LITTLE_ENDIAN },
    { NULL, 0,    0 }
};

When we add  { "UCS-2BE",        2,    BIG_ENDIAN } to gIconvGNUEncodings, everything is OK.

Is this an intended behavior or a bug?  

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@...
For additional commands, e-mail: c-dev-help@...

    [ https://issues.apache.org/jira/browse/XERCESC-1731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622847#action_12622847 ]

thomas.rothfuss commented on XERCESC-1731:
------------------------------------------

There are additional occurrences for this problem, e.g.

in LinuxPlatformUtils.cpp, XMLPlatformUtils::isRelative where a transcoded XMLString is compared with a not transcoded XMLCh:
    if (toCheck[0] == XMLCh('/'))

or calling
    const XERCES_CPP_NAMESPACE::DOMNode *dnp;
    char *pNodeName = XERCES_CPP_NAMESPACE::XMLString::transcode(dnp->getNodeName());
for a text node leads to an error because in DOMTextImpl.cpp, function DOMTextImpl::getNodeName() the returned string has XMLCh's which are not transcoded:
    static const XMLCh gtext[] = {chPound, chLatin_t, chLatin_e, chLatin_x, chLatin_t, chNull};


I enhanced the suggestion in IconvGNUTransService.cpp by looking at the byte order. PowerPC and x86 now have the same code:
    ...
    static const IconvGNUEncoding gIconvGNUEncodings[] = {
        { "UCS-2LE", 2, LITTLE_ENDIAN },
        { "ucs-2-internal", 2, LITTLE_ENDIAN },
        { "UCS-2BE", 2, BIG_ENDIAN },
        { NULL, 0, 0 }
    };
    ...
    IconvGNUTransService::IconvGNUTransService()
        : IconvGNUWrapper(), fUnicodeCP(0)
    {
    ...
        unsigned int encoding = LITTLE_ENDIAN;
        XMLCh xmlTestChar = XMLCh('1');
        char* pc = (char*)(&xmlTestChar);
        if (*pc == 0)
          encoding = BIG_ENDIAN;
        else
          encoding = LITTLE_ENDIAN;


        // Select the native unicode characters encoding schema
        const IconvGNUEncoding *eptr;
        // first - try to use the schema with character size, equil to XMLCh
        for (eptr = gIconvGNUEncodings; eptr->fSchema; eptr++) {
            if (eptr->fUChSize != sizeof(XMLCh))
                continue;
            if (encoding != eptr->fUBO)
              continue;
    ...

> Open file failed on MIPS because chForwardSlash in wrong byte-order
> -------------------------------------------------------------------
>
>                 Key: XERCESC-1731
>                 URL: https://issues.apache.org/jira/browse/XERCESC-1731
>             Project: Xerces-C++
>          Issue Type: Bug
>          Components: Utilities
>    Affects Versions: 2.7.0
>         Environment: MIPS
> Linux 2.6.16
> GNU iconv
>            Reporter: Yunhai Zhang
>            Priority: Critical
>
> We try to migrate some code to MIPS paltform, and got a failer while parsing an xml file using xerces-c++.
> So we check the code and found that when a LocalFileInputSource is constructed, the file name is composed as following:
>         XMLString::copyString(fullDir, curDir);
>         fullDir[curDirLen] = chForwardSlash;
>         XMLString::copyString(&fullDir[curDirLen+1], filePath);
> and chForwardSlash is define as following:        
>         const XMLCh chForwardSlash          = 0x2F;
> In our MIPS platform, this variant is in big-endian, but curDir and filePath are in little-endian, so we got a wrong fullDir.
> The reason why curDir and filePath are in little-endian is that IconvGNUTranscoder only use little-endian transecoder:
> static const IconvGNUEncoding    gIconvGNUEncodings[] = {
>     { "UCS-2LE",        2,    LITTLE_ENDIAN },
>     { "ucs-2-internal",        2,    LITTLE_ENDIAN },
>     { NULL, 0,    0 }
> };
> When we add  { "UCS-2BE",        2,    BIG_ENDIAN } to gIconvGNUEncodings, everything is OK.
> Is this an intended behavior or a bug?  

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@...
For additional commands, e-mail: c-dev-help@...

     [ https://issues.apache.org/jira/browse/XERCESC-1731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Boris Kolpackov closed XERCESC-1731.
------------------------------------

       Resolution: Fixed
    Fix Version/s: 3.0.1

I believe this has been fixed in 3.0.1.

> Open file failed on MIPS because chForwardSlash in wrong byte-order
> -------------------------------------------------------------------
>
>                 Key: XERCESC-1731
>                 URL: https://issues.apache.org/jira/browse/XERCESC-1731
>             Project: Xerces-C++
>          Issue Type: Bug
>          Components: Utilities
>    Affects Versions: 2.7.0
>         Environment: MIPS
> Linux 2.6.16
> GNU iconv
>            Reporter: Yunhai Zhang
>            Priority: Critical
>             Fix For: 3.0.1
>
>
> We try to migrate some code to MIPS paltform, and got a failer while parsing an xml file using xerces-c++.
> So we check the code and found that when a LocalFileInputSource is constructed, the file name is composed as following:
>         XMLString::copyString(fullDir, curDir);
>         fullDir[curDirLen] = chForwardSlash;
>         XMLString::copyString(&fullDir[curDirLen+1], filePath);
> and chForwardSlash is define as following:        
>         const XMLCh chForwardSlash          = 0x2F;
> In our MIPS platform, this variant is in big-endian, but curDir and filePath are in little-endian, so we got a wrong fullDir.
> The reason why curDir and filePath are in little-endian is that IconvGNUTranscoder only use little-endian transecoder:
> static const IconvGNUEncoding    gIconvGNUEncodings[] = {
>     { "UCS-2LE",        2,    LITTLE_ENDIAN },
>     { "ucs-2-internal",        2,    LITTLE_ENDIAN },
>     { NULL, 0,    0 }
> };
> When we add  { "UCS-2BE",        2,    BIG_ENDIAN } to gIconvGNUEncodings, everything is OK.
> Is this an intended behavior or a bug?  

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@...
For additional commands, e-mail: c-dev-help@...