You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by "Yunhai Zhang (JIRA)" <xe...@xml.apache.org> on 2007/08/03 08:40:52 UTC
[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@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
[jira] Commented: (XERCESC-1731) Open file failed on MIPS because
chForwardSlash in wrong byte-order
Posted by "thomas.rothfuss (JIRA)" <xe...@xml.apache.org>.
[ 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@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
[jira] Closed: (XERCESC-1731) Open file failed on MIPS because
chForwardSlash in wrong byte-order
Posted by "Boris Kolpackov (JIRA)" <xe...@xml.apache.org>.
[ 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@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org