[jira] [Resolved] (XERCESC-2234) Xerces does not correctly interpret negative jaxp processing limits as "NO LIMIT"

[Alberto Massari (Jira)]

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

Alberto Massari resolved XERCESC-2234.
--
Resolution: Invalid

This is the JIRA for Xerces-C++, not Xerces-J. Please report it to the correct 
project

> Xerces does not correctly interpret negative jaxp processing limits as "NO 
> LIMIT" 
> --
>
> Key: XERCESC-2234
> URL: https://issues.apache.org/jira/browse/XERCESC-2234
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Validating Parser (XML Schema)
>Affects Versions: 3.2.3
>Reporter: Spencer Stecko
>Priority: Minor
>
> According to the oracle documentation, many of the limits to jaxp processing 
> settings can be set to zero or a number less than zero to indicate no limit: 
> [https://docs.oracle.com/javase/tutorial/jaxp/limits/limits.html]
>  
> However, when I do this (with jdk.xml.maxOccurLimit), I get the following 
> stack trace:
>  
> {code:java}
> Caused by: org.xml.sax.SAXParseException: Current configuration of the parser 
> doesn't allow the expansion of a content model for a complex type to contain 
> more than -1 nodes.
>     at 
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:204)
>     at 
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:178)
>     at 
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:400)
>     at 
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.reportSchemaErr(XSDHandler.java:4253)
>     at 
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.reportSchemaFatalError(XSDHandler.java:4232)
>     at 
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSAttributeChecker.reportSchemaFatalError(XSAttributeChecker.java:1569)
>     at 
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSAttributeChecker.checkAttributes(XSAttributeChecker.java:1201)
>     at 
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSAttributeChecker.checkAttributes(XSAttributeChecker.java:960)
>     at 
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDAbstractParticleTraverser.traverseSeqChoice(XSDAbstractParticleTraverser.java:204)
>     at 
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDAbstractParticleTraverser.traverseSequence(XSDAbstractParticleTraverser.java:160)
>     at 
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDComplexTypeTraverser.processComplexContent(XSDComplexTypeTraverser.java:1043)
>     at 
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDComplexTypeTraverser.traverseComplexTypeDecl(XSDComplexTypeTraverser.java:335)
>     at 
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDComplexTypeTraverser.traverseGlobal(XSDComplexTypeTraverser.java:191)
>     at 
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.traverseSchemas(XSDHandler.java:1479)
>     at 
> com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.parseSchema(XSDHandler.java:662)
>     at 
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadSchema(XMLSchemaLoader.java:617)
>     at 
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:576)
>     at 
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:542)
>     at 
> com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory.newSchema(XMLSchemaFactory.java:276)
>     at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.java:669) 
> {code}
>  
> I have no idea what this repo I found is, but it appears to include some sort 
> of mirror of the apache xerces codebase, and the bug is clearly visible here: 
> [https://github.com/elastic/openjdkMirror/blob/f437b1097e6a395e91382cdfc7ec94355b554c51/jaxp/src/com/sun/org/apache/xerces/internal/utils/XMLSecurityManager.java#L378]
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Xerces V3.2.3 release candidate - call for vote

[Alberto Massari]

+1.
Thanks Scott,
Alberto

Il 07/04/20 17:00, Cantor, Scott ha scritto:

I have posted a release candidate [1] on my project site for evaluation (signed 
with my key) and would like to call for a vote to release, ending Friday.

The issues fixed are at [2], they're largely minor and mostly build related.

This is my +1.

-- Scott

[1] https://shibboleth.net/downloads/prerelease/
[2] 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10510&version=12344135


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org




-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Resolved] (XERCESC-2177) invalid windows version check for `onXPOrLater`

[Alberto Massari (Jira)]

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

Alberto Massari resolved XERCESC-2177.
--
Resolution: Fixed

> invalid windows version check for `onXPOrLater`
> ---
>
> Key: XERCESC-2177
> URL: https://issues.apache.org/jira/browse/XERCESC-2177
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 3.2.0, 3.2.1, 3.2.2
> Environment: win10 x64
>Reporter: Vvv
>    Assignee: Alberto Massari
>Priority: Minor
>  Labels: beginner, easyfix, windows
> Fix For: 3.2.3
>
>   Original Estimate: 5m
>  Remaining Estimate: 5m
>
> in 
> {{xerces-c-3.2.2\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp:324}}
>  
> {{ if ((OSVer.dwPlatformId == VER_PLATFORM_WIN32_NT) &&}}
> {{ ((OSVer.dwMajorVersion == 5) && (OSVer.dwMinorVersion > 0)))}}
> {{ {}}
> {{  onXPOrLater = true;}}
> {{ }}}
>  on win10 {{OSVer.dwMajorVersion = 6}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Assigned] (XERCESC-2177) invalid windows version check for `onXPOrLater`

[Alberto Massari (Jira)]

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

Alberto Massari reassigned XERCESC-2177:


Assignee: Alberto Massari

> invalid windows version check for `onXPOrLater`
> ---
>
> Key: XERCESC-2177
> URL: https://issues.apache.org/jira/browse/XERCESC-2177
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 3.2.0, 3.2.1, 3.2.2
> Environment: win10 x64
>Reporter: Vvv
>    Assignee: Alberto Massari
>Priority: Minor
>  Labels: beginner, easyfix, windows
> Fix For: 3.2.3
>
>   Original Estimate: 5m
>  Remaining Estimate: 5m
>
> in 
> {{xerces-c-3.2.2\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp:324}}
>  
> {{ if ((OSVer.dwPlatformId == VER_PLATFORM_WIN32_NT) &&}}
> {{ ((OSVer.dwMajorVersion == 5) && (OSVer.dwMinorVersion > 0)))}}
> {{ {}}
> {{  onXPOrLater = true;}}
> {{ }}}
>  on win10 {{OSVer.dwMajorVersion = 6}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Resolved] (XERCESC-2179) access violation in win32transservice.cpp with 64 bit compile

[Alberto Massari (Jira)]

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

Alberto Massari resolved XERCESC-2179.
--
Resolution: Not A Problem

This seems a problem due to multiple Initialize/Terminate calls

> access violation in win32transservice.cpp with 64 bit compile
> -
>
> Key: XERCESC-2179
> URL: https://issues.apache.org/jira/browse/XERCESC-2179
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: DOM
>Affects Versions: 3.2.2
>Reporter: martin goodall
>Assignee: Alberto Massari
>Priority: Blocker
> Fix For: 3.2.3
>
> Attachments: Win32TransService.cpp
>
>
> calls to ::Reg... to get registry info are passing in stack variables that 
> are 8 bytes long into functions that overwrite 16 bytes, causing memory 
> overwrite and very random segs.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Resolved] (XERCESC-2180) Handle surrogate pairs when reading a QName instead of ASSERTing

[Alberto Massari (Jira)]

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

Alberto Massari resolved XERCESC-2180.
--
Resolution: Fixed

> Handle surrogate pairs when reading a QName instead of ASSERTing
> 
>
> Key: XERCESC-2180
> URL: https://issues.apache.org/jira/browse/XERCESC-2180
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Miscellaneous
>Affects Versions: 3.2.0, 3.2.1, 3.2.2
>    Reporter: Alberto Massari
>Assignee: Alberto Massari
>Priority: Major
> Fix For: 3.2.3
>
> Attachments: crash.xml
>
>
> As discovered by Vincent Ulitzsch:
>  {quote}The assertion fails when parsing a malformed xml-file, we attached a 
> crashing testcase. We would suggest fixing this assertion, since it opens up 
> the possibility
> for Denial of Service attacks via malformed xml files.{quote}
> The code expects that tre transcoder places a pair of surrogate characters in 
> the Unicode buffers, but the UTF16 transcoder simply copies the data without 
> checking if it ends in the middle of a surrogate pair. So the fix is to 
> replace the assertion with a request for more data, and if there is no data 
> or if it's not the other part of the surrogate, exit the method as we would 
> be doing if we found the invalid character inside the buffer



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Assigned] (XERCESC-2180) Handle surrogate pairs when reading a QName instead of ASSERTing

[Alberto Massari (Jira)]

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

Alberto Massari reassigned XERCESC-2180:


Assignee: Alberto Massari

> Handle surrogate pairs when reading a QName instead of ASSERTing
> 
>
> Key: XERCESC-2180
> URL: https://issues.apache.org/jira/browse/XERCESC-2180
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Miscellaneous
>Affects Versions: 3.2.0, 3.2.1, 3.2.2
>    Reporter: Alberto Massari
>Assignee: Alberto Massari
>Priority: Major
> Fix For: 3.2.3
>
> Attachments: crash.xml
>
>
> As discovered by Vincent Ulitzsch:
>  {quote}The assertion fails when parsing a malformed xml-file, we attached a 
> crashing testcase. We would suggest fixing this assertion, since it opens up 
> the possibility
> for Denial of Service attacks via malformed xml files.{quote}
> The code expects that tre transcoder places a pair of surrogate characters in 
> the Unicode buffers, but the UTF16 transcoder simply copies the data without 
> checking if it ends in the middle of a surrogate pair. So the fix is to 
> replace the assertion with a request for more data, and if there is no data 
> or if it's not the other part of the surrogate, exit the method as we would 
> be doing if we found the invalid character inside the buffer



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Commented] (XERCESC-2180) Handle surrogate pairs when reading a QName instead of ASSERTing

[Alberto Massari (Jira)]

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

Alberto Massari commented on XERCESC-2180:
--

I have a fix in the ReaderMgr; I added a test in the regression suite, but I 
need to make some changes in the test suite to avoid using the XMLSchema 
support for XML-only tests

> Handle surrogate pairs when reading a QName instead of ASSERTing
> 
>
> Key: XERCESC-2180
> URL: https://issues.apache.org/jira/browse/XERCESC-2180
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Miscellaneous
>Affects Versions: 3.2.0, 3.2.1, 3.2.2
>    Reporter: Alberto Massari
>Priority: Major
> Fix For: 3.2.3
>
> Attachments: crash.xml
>
>
> As discovered by Vincent Ulitzsch:
>  {quote}The assertion fails when parsing a malformed xml-file, we attached a 
> crashing testcase. We would suggest fixing this assertion, since it opens up 
> the possibility
> for Denial of Service attacks via malformed xml files.{quote}
> The code expects that tre transcoder places a pair of surrogate characters in 
> the Unicode buffers, but the UTF16 transcoder simply copies the data without 
> checking if it ends in the middle of a surrogate pair. So the fix is to 
> replace the assertion with a request for more data, and if there is no data 
> or if it's not the other part of the surrogate, exit the method as we would 
> be doing if we found the invalid character inside the buffer



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Created] (XERCESC-2180) Handle surrogate pairs when reading a QName instead of ASSERTing

[Alberto Massari (Jira)]

Alberto Massari created XERCESC-2180:


 Summary: Handle surrogate pairs when reading a QName instead of 
ASSERTing
 Key: XERCESC-2180
 URL: https://issues.apache.org/jira/browse/XERCESC-2180
 Project: Xerces-C++
  Issue Type: Bug
  Components: Utilities
Reporter: Alberto Massari
Assignee: Alberto Massari
 Attachments: crash.xml

As discovered by Vincent Ulitzsch:

 {quote}The assertion fails when parsing a malformed xml-file, we attached a 
crashing testcase. We would suggest fixing this assertion, since it opens up 
the possibility
for Denial of Service attacks via malformed xml files.{quote}

The code expects that tre transcoder places a pair of surrogate characters in 
the Unicode buffers, but the UTF16 transcoder simply copies the data without 
checking if it ends in the middle of a surrogate pair. So the fix is to replace 
the assertion with a request for more data, and if there is no data or if it's 
not the other part of the surrogate, exit the method as we would be doing if we 
found the invalid character inside the buffer



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Commented] (XERCESC-2179) access violation in win32transservice.cpp with 64 bit compile

[Alberto Massari (Jira)]

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

Alberto Massari commented on XERCESC-2179:
--

That code is correct too:

 {code} 

362 unsigned long theSize;
...
405 unsigned long theType;
406 unsigned int CPId;
407 unsigned int IEId;
408 
409 theSize = sizeof(unsigned int);
410 if (::RegQueryValueExA
411 (
412 encodingKey
413 , "Codepage"
414 , 0
415 , &theType
416 , (unsigned char*)&CPId
417 , &theSize) != ERROR_SUCCESS)
418 {
419 ::RegCloseKey(encodingKey);
420 continue;
421 }
{code}

The Codepage (and the InternetEncoding quried later) are defined as REG_DWORD, 
so they need just 32 bit to be stored, and both the CPId and the 
sizeof(unsigned int) are enough to hold its value, with no need to add space 
for a NULL terminator that in any case would be a wrong value to add just to 
theSize (because CPId would not have room for 5 bytes, only for 4).

Changing the code to use the Windows macros would help reading the code, but I 
don't see an actual issue here

> access violation in win32transservice.cpp with 64 bit compile
> -
>
> Key: XERCESC-2179
> URL: https://issues.apache.org/jira/browse/XERCESC-2179
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: DOM
>Affects Versions: 3.2.2
>    Reporter: martin goodall
>Assignee: Alberto Massari
>Priority: Blocker
> Fix For: 3.2.3
>
> Attachments: Win32TransService.cpp
>
>
> calls to ::Reg... to get registry info are passing in stack variables that 
> are 8 bytes long into functions that overwrite 16 bytes, causing memory 
> overwrite and very random segs.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Comment Edited] (XERCESC-2179) access violation in win32transservice.cpp with 64 bit compile

[Alberto Massari (Jira)]

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

Alberto Massari edited comment on XERCESC-2179 at 11/4/19 3:50 PM:
---

That code is correct too:

 {code} 

362 unsigned long theSize;
...
405 unsigned long theType;
406 unsigned int CPId;
407 unsigned int IEId;
408 
409 theSize = sizeof(unsigned int);
410 if (::RegQueryValueExA
411 (
412 encodingKey
413 , "Codepage"
414 , 0
415 , &theType
416 , (unsigned char*)&CPId
417 , &theSize) != ERROR_SUCCESS)
418 {
419 ::RegCloseKey(encodingKey);
420 continue;
421 }
{code}

The Codepage (and the InternetEncoding queried later) are defined as REG_DWORD, 
so they need just 32 bit to be stored, and both the CPId and the 
sizeof(unsigned int) are enough to hold its value, with no need to add space 
for a NULL terminator that in any case would be a wrong value to add just to 
theSize (because CPId would not have room for 5 bytes, only for 4).

Changing the code to use the Windows macros would help reading the code, but I 
don't see an actual issue here


was (Author: amassari):
That code is correct too:

 {code} 

362 unsigned long theSize;
...
405 unsigned long theType;
406 unsigned int CPId;
407 unsigned int IEId;
408 
409 theSize = sizeof(unsigned int);
410 if (::RegQueryValueExA
411 (
412 encodingKey
413 , "Codepage"
414 , 0
415 , &theType
416 , (unsigned char*)&CPId
417 , &theSize) != ERROR_SUCCESS)
418 {
419 ::RegCloseKey(encodingKey);
420 continue;
421 }
{code}

The Codepage (and the InternetEncoding quried later) are defined as REG_DWORD, 
so they need just 32 bit to be stored, and both the CPId and the 
sizeof(unsigned int) are enough to hold its value, with no need to add space 
for a NULL terminator that in any case would be a wrong value to add just to 
theSize (because CPId would not have room for 5 bytes, only for 4).

Changing the code to use the Windows macros would help reading the code, but I 
don't see an actual issue here

> access violation in win32transservice.cpp with 64 bit compile
> -
>
> Key: XERCESC-2179
> URL: https://issues.apache.org/jira/browse/XERCESC-2179
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: DOM
>Affects Versions: 3.2.2
>Reporter: martin goodall
>Assignee: Alberto Massari
>Priority: Blocker
> Fix For: 3.2.3
>
> Attachments: Win32TransService.cpp
>
>
> calls to ::Reg... to get registry info are passing in stack variables that 
> are 8 bytes long into functions that overwrite 16 bytes, causing memory 
> overwrite and very random segs.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Comment Edited] (XERCESC-2179) access violation in win32transservice.cpp with 64 bit compile

[Alberto Massari (Jira)]

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

Alberto Massari edited comment on XERCESC-2179 at 11/4/19 3:23 PM:
---

The current code in the trunk is here: 
[http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l159]

{code}
{
163 unsigned long theType;
164 unsigned long theSize = nameBufSz;
165 return (::RegQueryValueExA
166 (
167 encodingKey
168 , "AliasForCharset"
169 , 0
170 , &theType
171 , (unsigned char*)aliasBuf
172 , &theSize
173 ) == ERROR_SUCCESS);
174 }
{code}

theType is not unsigned int, it's unsigned long that is identical to DWORD 
theType after the preprocessor expands the macro.

 


was (Author: amassari):
The current code in the trunk is here: 
[http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l159]

 
|{|
|[163|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l163]|unsigned
 long theType;|
|[164|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l164]|unsigned
 long theSize = nameBufSz;|
|[165|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l165]|return
 (::RegQueryValueExA|
|[166|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l166]|(|
|[167|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l167]|encodingKey|
|[168|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l168]|,
 "AliasForCharset"|
|[169|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l169]|,
 0|
|[170|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l170]|,
 &theType|
|[171|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l171]|,
 (unsigned char*)aliasBuf|
|[172|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l172]|,
 &theSize|
|[173|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l173]|)
 == ERROR_SUCCESS);|
|[174|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l174]|}|

theType is not unsigned int, it's unsigned long that is identical to DWORD 
theType after the preprocessor expands the macro.

 

> access violation in win32transservice.cpp with 64 bit compile
> -
>
> Key: XERCESC-2179
> URL: https://issues.apache.org/jira/browse/XERCESC-2179
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: DOM
>Affects Versions: 3.2.2
>Reporter: martin goodall
>Assignee: Alberto Massari
>Priority: Blocker
> Fix For: 3.2.3
>
> Attachments: Win32TransService.cpp
>
>
> calls to ::Reg... to get registry info are passing in stack variables that 
> are 8 bytes long into functions that overwrite 16 bytes, causing memory 
> overwrite and very random segs.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Commented] (XERCESC-2179) access violation in win32transservice.cpp with 64 bit compile

[Alberto Massari (Jira)]

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

Alberto Massari commented on XERCESC-2179:
--

The current code in the trunk is here: 
[http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l159]

 
|{|
|[163|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l163]|unsigned
 long theType;|
|[164|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l164]|unsigned
 long theSize = nameBufSz;|
|[165|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l165]|return
 (::RegQueryValueExA|
|[166|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l166]|(|
|[167|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l167]|encodingKey|
|[168|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l168]|,
 "AliasForCharset"|
|[169|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l169]|,
 0|
|[170|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l170]|,
 &theType|
|[171|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l171]|,
 (unsigned char*)aliasBuf|
|[172|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l172]|,
 &theSize|
|[173|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l173]|)
 == ERROR_SUCCESS);|
|[174|http://svn.apache.org/viewvc/xerces/c/trunk/src/xercesc/util/Transcoders/Win32/Win32TransService.cpp?view=markup#l174]|}|

theType is not unsigned int, it's unsigned long that is identical to DWORD 
theType after the preprocessor expands the macro.

 

> access violation in win32transservice.cpp with 64 bit compile
> -
>
> Key: XERCESC-2179
> URL: https://issues.apache.org/jira/browse/XERCESC-2179
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: DOM
>Affects Versions: 3.2.2
>        Reporter: martin goodall
>Assignee: Alberto Massari
>Priority: Blocker
> Fix For: 3.2.3
>
> Attachments: Win32TransService.cpp
>
>
> calls to ::Reg... to get registry info are passing in stack variables that 
> are 8 bytes long into functions that overwrite 16 bytes, causing memory 
> overwrite and very random segs.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Commented] (XERCESC-2179) access violation in win32transservice.cpp with 64 bit compile

[Alberto Massari (Jira)]

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

Alberto Massari commented on XERCESC-2179:
--

Don't get me wrong, I'm not questioning the size of the data. I am saying that 
the code

 

unsigned long theSize;

and

DWORD theSize;

are identical, and calling RegQueryValueExA using &theSize is still creating 
the correct 64 bit pointer to a variable of the expected size.

 

As for adding the the +1, it would make a difference only when attempting to 
read a string from the registry that is exaclty 1024 characters long. In that 
case, by invoking the API with a value of 1024 (even if the buffer has been 
allocated with a storage for 1025 bytes), we would get a ERROR_MORE_DATA 
instead of a ERROR_SUCCESS. No memory overrun, just a failure to load that 
registry entry (but there should be no encoding with a name so big).

When the registry key is a number, the space for the NULL terminator is not 
added ("If the data has the REG_SZ, REG_MULTI_SZ or REG_EXPAND_SZ type, this 
size includes any terminating *null* character or characters unless the data 
was stored without them")

> access violation in win32transservice.cpp with 64 bit compile
> -
>
> Key: XERCESC-2179
> URL: https://issues.apache.org/jira/browse/XERCESC-2179
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: DOM
>Affects Versions: 3.2.2
>        Reporter: martin goodall
>Assignee: Alberto Massari
>Priority: Blocker
> Fix For: 3.2.3
>
> Attachments: Win32TransService.cpp
>
>
> calls to ::Reg... to get registry info are passing in stack variables that 
> are 8 bytes long into functions that overwrite 16 bytes, causing memory 
> overwrite and very random segs.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Commented] (XERCESC-2179) access violation in win32transservice.cpp with 64 bit compile

[Alberto Massari (Jira)]

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

Alberto Massari commented on XERCESC-2179:
--

The definition for RegQueryValueExA 
([https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regqueryvalueexa)]
 uses LPDWORD, but DWORD is defined as "unsigned long" 
([https://docs.microsoft.com/en-us/windows/win32/winprog/windows-data-types)]

 
|*DWORD*|A 32-bit unsigned integer. The range is 0 through 4294967295 decimal.
 This type is declared in IntSafe.h as follows:
 {{typedef unsigned long DWORD;}}|

 

So, there should be no difference between an unsigned long and a DWORD.

As for the changes that add a +1 to some string lengths, the size of the buffer 
is set to 1024, and it should be big enough to hold any possible encoding name; 
in other cases the data to be read is a number, so the NULL terminator would 
not be added.

Are you targeting a non-desktop version of Windows? I don't see how that code 
could fail

> access violation in win32transservice.cpp with 64 bit compile
> -
>
> Key: XERCESC-2179
> URL: https://issues.apache.org/jira/browse/XERCESC-2179
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: DOM
>Affects Versions: 3.2.2
>    Reporter: martin goodall
>Assignee: Alberto Massari
>Priority: Blocker
> Fix For: 3.2.3
>
> Attachments: Win32TransService.cpp
>
>
> calls to ::Reg... to get registry info are passing in stack variables that 
> are 8 bytes long into functions that overwrite 16 bytes, causing memory 
> overwrite and very random segs.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Assigned] (XERCESC-2179) access violation in win32transservice.cpp with 64 bit compile

[Alberto Massari (Jira)]

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

Alberto Massari reassigned XERCESC-2179:


Assignee: Alberto Massari

> access violation in win32transservice.cpp with 64 bit compile
> -
>
> Key: XERCESC-2179
> URL: https://issues.apache.org/jira/browse/XERCESC-2179
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: DOM
>Affects Versions: 3.2.2
>Reporter: martin goodall
>Assignee: Alberto Massari
>Priority: Blocker
> Fix For: 3.2.3
>
> Attachments: Win32TransService.cpp
>
>
> calls to ::Reg... to get registry info are passing in stack variables that 
> are 8 bytes long into functions that overwrite 16 bytes, causing memory 
> overwrite and very random segs.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Node to string is corrupting the characters

[Alberto Massari]

Hi Vinayak,
please include a full repro case, including the code that creates the 
"node" DOMNode with the specific characters that are not mapped 
correctly. Also, on which platform are you running, and what transcoding 
engine did you compile Xerces with (ICU, etc..)?


Alberto

Il 04/11/19 07:09, Datir, Vinayak ha scritto:


Hi All,

    We are trying convert the DOM into string. But it is 
converting few characters into question mark. Characters are within 
the ISO 8859-1 code page.


    Below is sample code for converting the DOM to string

DOMImplementation *impl = 
DOMImplementationRegistry::getDOMImplementation(0);


DOMLSSerializer* serializer = 
((DOMImplementationLS*)impl)->createLSSerializer();


DOMLSOutput* out = ((DOMImplementationLS*)impl)->createLSOutput();

XMLFormatTarget *target  = new MemBufFormatTarget();

out->setByteStream(target);

*out->setEncoding( STRINGTOXMLCHAR("ISO-8859-1"));*

serializer->write(node, out);

char* theXMLString_Encoded = (char*)

((MemBufFormatTarget*)target)->getRawBuffer();

*buffer = (char *) MEM_alloc(strlen(theXMLString_Encoded) + 1);

tc_strcpy(*buffer, theXMLString_Encoded);

serializer->release();

out->release();

delete target;

Thanks,

Vinayak.

Re: How to load nbsp into dom

[Alberto Massari]

Hi Vinaya,
are you reading all the DOM nodes? The parser splits text buffers into 
separate nodes when an entity character is found (in case the entity 
expands to a complex subtree) so it's possible that the rest of the text 
is just in the next DOMText node.


Alberto

Il 04/11/19 07:39, Datir, Vinayak ha scritto:


Hi All,

    We want to load HTML document containing nbsp into 
DOM. But It DOM document is getting trimmed after first nbsp.


    How to load HTML characters into DOM document?

Thanks,

Vinaya.

Re: Call for vote on migrating Xerces-C++ repositories to Git

[Alberto Massari]

+1

Alberto

Il 22/04/19 19:26, Gareth Reakes ha scritto:


+1

G

Sent from my iPhone


On 22 Apr 2019, at 18:46, Cantor, Scott  wrote:

+1 from me

-- Scott

On 4/22/19, 12:27 PM, "Boris Kolpackov"  wrote:

I would like to call for a vote to migrate Xerces-C++ SVN repositories
to Git, specifically, to the Apache Gitbox service:

https://gitbox.apache.org/

This is my +1.


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org





-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Xerces 3.2 RC2 released, call for vote

[Alberto Massari]

+1 for me

Alberto

Il 28/08/17 18:04, Cantor, Scott ha scritto:

Roger, did you happen to test Visual Studio 2017 (VC15)?

I got a report from my colleague that it's missing a WIN32 define that's
preventing one of my changes to the DateTime class from building there
without adding it by hand.

Looks like a false alarm or something environmental with the solution file it 
generated on his box, seems to work for me as expected.


If you didn't try that, I'll rescind the vote until I have a chance to debug it 
this
week. We don't have a third vote yet anyway.

But I do need a third vote.

-- Scott



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org




-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Commented] (XERCESC-2088) Bad casting from DOMTextImpl to DOMElementImpl

[Alberto Massari (JIRA)]

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

Alberto Massari commented on XERCESC-2088:
--

Let's say "we're depending", I am not the author of that code... 

> Bad casting from DOMTextImpl to DOMElementImpl
> --
>
> Key: XERCESC-2088
> URL: https://issues.apache.org/jira/browse/XERCESC-2088
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: DOM
>Affects Versions: 3.1.1, 3.1.2, 3.1.3, 3.1.4
> Environment: ubuntu 16.04 LTS, Intel(R) Core(TM) i7-6700 CPU @ 
> 3.40GHz, 16GB
>Reporter: Yuseok Jeon
> Fix For: 3.2.0
>
> Attachments: Actual_result.txt, relationship_tree.jpeg
>
>
> Hi all, 
> Our recently developed type confusion detection tool reports a type_confusion 
> error in the "xercesc/dom/imple/DOMCasts.hpp" 
> xercesc/dom/imple/DOMCasts.hpp, line 146
> static inline DOMNodeImpl *castToNodeImpl(const DOMNode *p)
> {
> DOMElementImpl *pE = (DOMElementImpl *)p;
> return &(pE->fNode);
> }
> p is pointing to the object allocated as DOMTextImpl, and it is casted into 
> DOMElementImpl. However, since DOMElementImpl is not a subobject of 
> DOMTextImpl, it is violating C++ standard rules 5.2.9/11 (down casting is 
> undefined if the object that the pointer to be casted points to is not a 
> suboject of down casting type) and causes undefined behaviors.
> There are similar type-confusion cases as below links. 
>  - (libstdc++) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60734
>  - (Firefox) https://bugzilla.mozilla.org/show_bug.cgi?id=1074280
> I attached a actual type confusion report and object relationship 
> information. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Commented] (XERCESC-2088) Bad casting from DOMTextImpl to DOMElementImpl

[Alberto Massari (JIRA)]

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

Alberto Massari commented on XERCESC-2088:
--

This is a cast required by the fact that each implementation class derives only 
from the interface class, and includes the implementation of the basic methods 
from DOMNode by embedding a DOMNodeImpl instance. This instance is always the 
first member of the implementation class, so actually it doesn't matter that 
the method does a cast to DOMElementImpl, as any other class would be just 
fine. If the compiler doesn't accept a C-style cast, maybe a 
reinterpret_cast could work

> Bad casting from DOMTextImpl to DOMElementImpl
> --
>
> Key: XERCESC-2088
> URL: https://issues.apache.org/jira/browse/XERCESC-2088
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: DOM
>Affects Versions: 3.1.1, 3.1.2, 3.1.3, 3.1.4
> Environment: ubuntu 16.04 LTS, Intel(R) Core(TM) i7-6700 CPU @ 
> 3.40GHz, 16GB
>Reporter: Yuseok Jeon
> Attachments: Actual_result.txt, relationship_tree.jpeg
>
>
> Hi all, 
> Our recently developed type confusion detection tool reports a type_confusion 
> error in the "xercesc/dom/imple/DOMCasts.hpp" 
> xercesc/dom/imple/DOMCasts.hpp, line 146
> static inline DOMNodeImpl *castToNodeImpl(const DOMNode *p)
> {
> DOMElementImpl *pE = (DOMElementImpl *)p;
> return &(pE->fNode);
> }
> p is pointing to the object allocated as DOMTextImpl, and it is casted into 
> DOMElementImpl. However, since DOMElementImpl is not a subobject of 
> DOMTextImpl, it is violating C++ standard rules 5.2.9/11 (down casting is 
> undefined if the object that the pointer to be casted points to is not a 
> suboject of down casting type) and causes undefined behaviors.
> There are similar type-confusion cases as below links. 
>  - (libstdc++) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60734
>  - (Firefox) https://bugzilla.mozilla.org/show_bug.cgi?id=1074280
> I attached a actual type confusion report and object relationship 
> information. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Error messages / ABI

[Alberto Massari]

Unless the decorated name of the enum includes the number of values, it 
should not change, and the ABI stays the same.
It may require that the developer handle the new error code, but I doubt 
that it happens very often. So, I think a 3.1.4 release is ok.


Alberto

Il 04/06/16 18:32, Cantor, Scott ha scritto:

Question to the rest of the remaining developers: is it an ABI change to add 
error messages/codes? I'm not familiar enough with the error handling machinery 
to know what's entailed in adding one, though I know there's an enum, and an 
XML file that's used to produce all the source code with the error messages.

I'm inclined to assume that it is an ABI change, which is a pain, but thought 
I'd check.

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org





-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Deleted] (XERCESC-2067) 844-307-5701 Outlook tech support phone number Outlook tech support telephone number here.Describe ((( Outlook support phone number.

[Alberto Massari (JIRA)]

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

Alberto Massari deleted XERCESC-2067:
-


> 844-307-5701 Outlook tech support phone number Outlook tech support telephone 
> number here.Describe ((( Outlook support phone number.
> 
>
> Key: XERCESC-2067
> URL: https://issues.apache.org/jira/browse/XERCESC-2067
> Project: Xerces-C++
>  Issue Type: Bug
>Reporter: annaadiwar0123
>
> escribe Call+1844-307-5701 Outlook tech support phone number Outlook tech 
> support telephone number here.Describe ((( Outlook support phone number... 
> ~Help Usa@ 844-307-5701..((( Outlook support number.. here.Outlook tech((1 
> 844-307-5701 Outlook pro c.u.s.t.o.m.e.r s.u.p.p.o.r.t n.u.m.b.e.r Outlook 
> T.e.c.h s.u.p.p.o.r.t ph.one n.u.m.b.e.r WBP Outlook technical support 
> number!!844-307-5701!!(( Outlook Tech Support phone number Outlook TECH 
> SUPPORT NUMBER!!844-307-5701!!((Outlook Customer Support Phone NUmber 
> Outlook Customer Service Number !!844-307-5701!!Outlook support Phone Number 
> Outlook help number-Outlook Helpline Number; Outlook help phone number, 
> Outlook Helpline Number, Outlook Tech Support Toll free Number, Outlook 
> Support Telephone Number, Outlook Tech Support Telephone number, Outlook Tech 
> Support contact number, Outlook support contact number, Outlook technical 
> support contact number, Outlook support phone number, Outlook support phone 
> number. Outlook customer support phone number Outlook Support Helpline 
> Number, Outlook contact number Outlook tech support phone number ~Help Usa@ 
> 844-307-5701..((( Outlook support phone number... ~Help Usa@ 
> 844-307-5701..((( Outlook support phone number... ~Help Usa@ 
> 844-307-5701..((( Outlook support phone number... ~Help Usa@ 844-307-5701.. 
> ((( Outlook support number... ~Help Usa@ 844-307-5701..((( Outlook help desk 
> phone number... ~Help Usa@ 1- 844-307-5701..((( Outlook help desk phone 
> number... ~Help Usa@ 844-307-5701..((( Outlook help desk phone number... 
> Contents [hide] Outlook support 1 844-307-5701 team phone numberGet Instant 
> Help Usa & Canada at 1 844-307-5701 Outlook customer support phone number , 
> Outlook customer service number , Outlook tech support number, Outlook 
> technical support number, Outlook customer care number , 
> Q.B1.844-307-5701Outlook pro help desk number , Outlook pro support phone 
> number Q.B1.844-307-5701 Outlook pro help desk number , Outlook pro support 
> phone number Outlook customer care phoe number , Outlook helpdesk support 
> phone number, Outlook helpdesk support number, Outlook helpdesk number, 
> Outlook support help number, Outlook support help number ~Help Usa@ 
> 844-307-5701..((( Outlook support phone number... ~Help Usa@ 1- 
> 844-307-5701..((( Outlook support phone number... ~Help Usa@ 
> 844-307-5701..((( Outlook support phone number... ~Help Usa@ 
> 844-307-5701..((( Outlook support number... ~Help Usa@ 844-307-5701.. ((( 
> Outlook help desk phone number... ~Help Usa@ 844-307-5701..((( Outlook help 
> desk phone number... ~Help Usa@ 844-307-5701..((( Outlook help desk phone 
> number... Contents [hide] 1 ::~Help Usa@ 844-307-5701..((( Outlook tech 
> support phone number... 2 ::~Help Usa@ 844-307-5701..((( Outlook tech support 
> number... 3 ::~Help Usa@ 844-307-5701..((( Outlook customer support number... 
> 4 Intuit Help... 844-307-5701 Outlook tech support phone number , Outlook 
> technical support phone number 5 Intuit Help... 844-307-5701 Outlook tech 
> support phone number , Outlook technical support phone number 6 Intuit 
> Help... 844-307-5701 Outlook tech support phone number , Outlook technical 
> support phone number ~Help Usa@ 1-844-307-5701...((( Outlook tech support 
> phone number...[edit] ~Help Usa@ 844-307-5701..((( Outlook tech support 
> number...[edit] == ~Help Usa@ 844-307-5701..((( Outlook tech support phone 
> number..==. Contents [hide] 1 ~Help Usa@ 844-307-5701..((( Outlook tech 
> support phone number... 2 ~Help Usa@ 844-307-5701.. ((( Outlook tech support 
> phone number... 3 ~Help Usa@ 844-307-5701..((( Outlook tech support phone 
> number... 4 ~Help Usa@ 844-307-5701..((( Outlook tech support phone number... 
> 5 ~Help Usa@ 1- 844-307-5701..((( Outlook tech support phone number... 6 
> ~Help Usa@ 844-307-5701..((( Outlook tech support phone number... 7 ~Help 
> Usa@ 844-307-5701..((( Outlook tech support phone number... 8 ~Help Usa@ 
> 844-307-5701..((( Outlook tech support phone number... 9 ~Help Usa@ 
> 844-307-5701.. (

Re: [VOTE] release of 3.1.3

[Alberto Massari]

Here's my +1

Thanks Scott,
Alberto

Il 11/02/16 09:15, Gareth Reakes ha scritto:

Hi guys,

The release candidate Scott put together at the beginning of the month 
has had no comments so we are good to go.

Here is my +1


PS - many thanks to Scott again for doing all the work

Gareth
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org





-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: How to solved this problem.

[Alberto Massari]

Double check if the new library has been compiled with the C++ 
namespace: in this case you need to either fully qualify the class to be 
xercesc::HandlerBase, or use the XERCES_CPP_NAMESPACE_USE macro to make 
it the default namespace.


Have a look at samples/src/SAXCount/SAXCountHandlers.hpp for a valid 
example of a SAX client.
For any other issue during the migration, look at 
http://xerces.apache.org/xerces-c/migrate-archive-3.html web page.


Alberto

Il 17/09/15 11:33, Karnthang, Songpon ha scritto:


Hi Dev.Team

I try to migration Xerces C++ from version 1.5.2 to 
3.1.2  but error occur when my class


Inherit HandlerBase from HandlerBase.hpp. How can I solve this 
problem. Please help to advise me.


Best Regards,

cid:image009.png@01D033FB.230FF2C0

Mr.Songpon Karnthang

(Application Developer)



Mobile : 083-194-4685

Phone : 02-832-5467

E-mail : songpon.karnth...@nttdata.com 



NTTDataLogo



/200 Moo 4, 25th Floor, Jasmine International Tower///

/Chaengwattana Road, Pakkret, Nonthaburi 11120 THAILAND/


__
Disclaimer: This email and any attachments are sent in strictest 
confidence

for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then 
delete
and destroy this email and any attachments without any further use, 
copying

or forwarding.

[jira] [Resolved] (XERCESC-2052) TranscodeToStr constructor throws TranscodingException claiming an invalid multi byte sequence when it is valid

[Alberto Massari (JIRA)]

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

Alberto Massari resolved XERCESC-2052.
--
   Resolution: Fixed
 Assignee: Alberto Massari
Fix Version/s: 3.2.0

> TranscodeToStr constructor throws TranscodingException claiming an invalid 
> multi byte sequence when it is valid
> ---
>
> Key: XERCESC-2052
> URL: https://issues.apache.org/jira/browse/XERCESC-2052
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 3.1.2
> Environment: Windows 32 and 64 bit compiled with VS2010
>Reporter: Nigel Meachen
>Assignee: Alberto Massari
> Fix For: 3.2.0
>
>
> The following constructor throws an EncodingException
> TranscodeToStr tTransCoder (L"中国制造 / 中國製造","UTF-8", 
> XMLPlatformUtils::fgMemoryManager);
> The code in TranscodeToStr::transcode allocates 26 bytes when 27 are needed, 
> however, it does not reach the reallocation logic as charsRead is returned by 
> trans->transcodeTo as zero. This only occurs in a Release build.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Updated] (XERCESC-2050) wrong use of delete keyword in DTest.cpp

[Alberto Massari (JIRA)]

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

Alberto Massari updated XERCESC-2050:
-
Fix Version/s: (was: 3.1.3)
   3.2.0

> wrong use of delete keyword in DTest.cpp
> 
>
> Key: XERCESC-2050
> URL: https://issues.apache.org/jira/browse/XERCESC-2050
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Samples/Tests
>Affects Versions: 3.1.2
>Reporter: Hanno Böck
>Assignee: Alberto Massari
>Priority: Minor
> Fix For: 3.2.0
>
> Attachments: xerces-c-fix-alloc-dealloc.diff
>
>
> In the file DTest.cpp there is a wrong use of the delete keyword. The 
> variable hugeString is allocated with:
> char* hugeString=new char[HUGE_STRING+1];
> It gets deallocated with:
> delete hugeString;
> When allocating a variable with "new type[size]" one has to deallocate with 
> "delete [] variable". These kinds of errors can be seen when compiling with 
> address sanitizer. I'll attach a patch.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Updated] (XERCESC-2053) typo in the documentation: "InputSource resolveEntity" -> "InputSource* resolveEntity"

[Alberto Massari (JIRA)]

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

Alberto Massari updated XERCESC-2053:
-
Fix Version/s: (was: 3.1.3)
   3.2.0

> typo in the documentation: "InputSource resolveEntity" -> "InputSource* 
> resolveEntity"
> --
>
> Key: XERCESC-2053
> URL: https://issues.apache.org/jira/browse/XERCESC-2053
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Documentation
>    Reporter: Erik Sjölund
>Assignee: Alberto Massari
>Priority: Trivial
> Fix For: 3.2.0
>
> Attachments: svn-diff.txt
>
>
> The code examples in the documentation does not match the EntityResolver 
> interface. There is a missing "*".  I attach the output from the command "svn 
> diff" from a fresh svn checkout with the typos corrected.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Resolved] (XERCESC-2053) typo in the documentation: "InputSource resolveEntity" -> "InputSource* resolveEntity"

[Alberto Massari (JIRA)]

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

Alberto Massari resolved XERCESC-2053.
--
   Resolution: Fixed
 Assignee: Alberto Massari
Fix Version/s: 3.1.3

> typo in the documentation: "InputSource resolveEntity" -> "InputSource* 
> resolveEntity"
> --
>
> Key: XERCESC-2053
> URL: https://issues.apache.org/jira/browse/XERCESC-2053
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Documentation
>    Reporter: Erik Sjölund
>Assignee: Alberto Massari
>Priority: Trivial
> Fix For: 3.1.3
>
> Attachments: svn-diff.txt
>
>
> The code examples in the documentation does not match the EntityResolver 
> interface. There is a missing "*".  I attach the output from the command "svn 
> diff" from a fresh svn checkout with the typos corrected.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Resolved] (XERCESC-2051) Overlapping memcpy call

[Alberto Massari (JIRA)]

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

Alberto Massari resolved XERCESC-2051.
--
Resolution: Duplicate

> Overlapping memcpy call
> ---
>
> Key: XERCESC-2051
> URL: https://issues.apache.org/jira/browse/XERCESC-2051
> Project: Xerces-C++
>  Issue Type: Bug
>Affects Versions: 3.1.2
>Reporter: Hanno Böck
>Priority: Minor
> Attachments: xerces-c-overlapping-memcpy.diff
>
>
> When running the test suite with address sanitizer enabled it will report an 
> overlapping memcpy call:
> < =
> < ==8236==ERROR: AddressSanitizer: memcpy-param-overlap: memory ranges 
> [0x006678c0,0x006678ca) and [0x006678c2, 0x006678cc) overlap
> < #0 0x7f1025853f24 
> (/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/libasan.so.1+0x2ff24)
> < #1 0x7f1024df4bf8 in xercesc_3_1::XMLString::moveChars(unsigned short*, 
> unsigned short const*, unsigned long) xercesc/util/XMLString.hpp:1446
> < #2 0x7f1024e627eb in xercesc_3_1::XMLString::collapseWS(unsigned 
> short*, xercesc_3_1::MemoryManager*) xercesc/util/XMLString.cpp:1813
> < #3 0x44a098 in DOMTest::testUtilFunctions() 
> src/DOM/DOMTest/DTest.cpp:5752
> < #4 0x412865 in main src/DOM/DOMTest/DTest.cpp:984
> < #5 0x7f10209b5f9f in __libc_start_main (/lib64/libc.so.6+0x1ff9f)
> < #6 0x405848 (/tmp/xerces-c-3.1.2/tests/.libs/DOMTest+0x405848)
> < 
> < 0x006678c0 is located 0 bytes inside of global variable 'tempStr' from 
> 'src/DOM/DOMTest/DTest.cpp' (0x6678c0) of size 8000
> < 0x006678c2 is located 2 bytes inside of global variable 'tempStr' from 
> 'src/DOM/DOMTest/DTest.cpp' (0x6678c0) of size 8000
> < SUMMARY: AddressSanitizer: memcpy-param-overlap ??:0 ??
> < ==8236==ABORTING
> memcpy calls to overlapping memory areas are not allowed. memmove can be used 
> in such instances. (I'll attach a patch that changes that, but I'd ask for it 
> to be reviewed by someone familiar with the code and check whether the 
> overlapping copying is really intended.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Resolved] (XERCESC-2050) wrong use of delete keyword in DTest.cpp

[Alberto Massari (JIRA)]

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

Alberto Massari resolved XERCESC-2050.
--
   Resolution: Fixed
Fix Version/s: 3.1.3

> wrong use of delete keyword in DTest.cpp
> 
>
> Key: XERCESC-2050
> URL: https://issues.apache.org/jira/browse/XERCESC-2050
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Samples/Tests
>Affects Versions: 3.1.2
>Reporter: Hanno Böck
>Assignee: Alberto Massari
>Priority: Minor
> Fix For: 3.1.3
>
> Attachments: xerces-c-fix-alloc-dealloc.diff
>
>
> In the file DTest.cpp there is a wrong use of the delete keyword. The 
> variable hugeString is allocated with:
> char* hugeString=new char[HUGE_STRING+1];
> It gets deallocated with:
> delete hugeString;
> When allocating a variable with "new type[size]" one has to deallocate with 
> "delete [] variable". These kinds of errors can be seen when compiling with 
> address sanitizer. I'll attach a patch.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Assigned] (XERCESC-2050) wrong use of delete keyword in DTest.cpp

[Alberto Massari (JIRA)]

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

Alberto Massari reassigned XERCESC-2050:


Assignee: Alberto Massari

> wrong use of delete keyword in DTest.cpp
> 
>
> Key: XERCESC-2050
> URL: https://issues.apache.org/jira/browse/XERCESC-2050
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Samples/Tests
>Affects Versions: 3.1.2
>Reporter: Hanno Böck
>Assignee: Alberto Massari
>Priority: Minor
> Fix For: 3.1.3
>
> Attachments: xerces-c-fix-alloc-dealloc.diff
>
>
> In the file DTest.cpp there is a wrong use of the delete keyword. The 
> variable hugeString is allocated with:
> char* hugeString=new char[HUGE_STRING+1];
> It gets deallocated with:
> delete hugeString;
> When allocating a variable with "new type[size]" one has to deallocate with 
> "delete [] variable". These kinds of errors can be seen when compiling with 
> address sanitizer. I'll attach a patch.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Resolved] (XERCESC-2049) memcpy used on overlapping memory regions causes sanity test failure

[Alberto Massari (JIRA)]

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

Alberto Massari resolved XERCESC-2049.
--
   Resolution: Fixed
Fix Version/s: 3.2.0
   3.1.3
 Assignee: Alberto Massari

> memcpy used on overlapping memory regions causes sanity test failure
> 
>
> Key: XERCESC-2049
> URL: https://issues.apache.org/jira/browse/XERCESC-2049
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 3.1.2
> Environment: Debian unstable (sid) and Debian stable (jessie) on amd64
>Reporter: Bill Blough
>    Assignee: Alberto Massari
> Fix For: 3.1.3, 3.2.0
>
> Attachments: moveChars_overlap.diff
>
>
> On Debian Jessie (libc6 2.19, libstdc++ 4.9.2) and newer, sanityTest.pl fails 
> its tests of XMLString::collapseWS.
> Tracing with GDB shows that XMLString::moveChars is corrupting the string.  I 
> think this is likely due to memcpy being used on overlapping memory regions.
> Replacing the memcpy in  moveChars with memmove fixes the issue on my 
> systems.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: [VOTE] release of 3.1.2

[Alberto Massari]

Here's my +1 too. And also my thanks to Scott for the time spent in 
arranging this release.


Alberto

Il 18/03/15 16:28, Gareth Reakes ha scritto:

Hey guys,

Here is my +1.

Gareth

PS - thanks for all the work Scott

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org





-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Xerces-C 3.1.2 beta-1 available, call for testing

[Alberto Massari]

Hi Scott,
first of all, thank you for taking care of the release; I compiled the 
source on Windows using VC9, VC11 and VC12; I have noticed that the 
solution file for VC12 is missing the correct version, so it is opened 
by VC11. I will be fixing this shortly on both trunk and branch


Alberto

Il 03/03/15 20:30, Cantor, Scott ha scritto:

A pre-release source distribution of Xerces-C V3.1.2 is available [1],
signed by me, and this is an official call for testers and feedback. The
list of bug fixes in this release can be found in Jira [1], and the PMC
would like to start the release process next week, so please test any
supported platforms you can.

This distribution contains all the Windows project files available, and
has been built successfully with both VS 2010 and 2012 so far.

If any problems arise I should be able to produce updated sources for
further testing throughout this week/end.

Thanks,
-- Scott Cantor, on behalf of the Xerces-C project

[1] http://people.apache.org/~scantor/
[2] http://go.osu.edu/ysq




-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Resolved] (XERCESC-2024) LocalFileFormatTarget leaks file handle

[Alberto Massari (JIRA)]

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

Alberto Massari resolved XERCESC-2024.
--

Resolution: Fixed

Sorry, this bug is a zombie...

> LocalFileFormatTarget leaks file handle
> ---
>
> Key: XERCESC-2024
> URL: https://issues.apache.org/jira/browse/XERCESC-2024
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Miscellaneous
>Reporter: Vemund Handeland
>    Assignee: Alberto Massari
> Fix For: 3.2.0
>
> Attachments: LocalFileFormatTarget.cpp.patch
>
>
> The call to XMLPlatformUtils::writeBufferToFile in the LocalFileFormatTarget 
> destructor might throw an exception. A typical use case is running out of 
> disk space.
> In this case the file handle will not be closed



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Commented] (XERCESC-1235) Xerces-C++ does not build with gcc 3.4.0

[Alberto Massari (JIRA)]

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

Alberto Massari commented on XERCESC-1235:
--

This looks like a missing #include , but you should ask the Xalan 
team...

> Xerces-C++ does not build with gcc 3.4.0
> 
>
> Key: XERCESC-1235
> URL: https://issues.apache.org/jira/browse/XERCESC-1235
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 2.5.0
> Environment: Gcc 3.4.0
> Slackware GNU/Linux 10.0  
>Reporter: ismail dönmez
>
> When trying to build xerces-c with gcc 3.4.0 I get error :
> make -C impl
> make[2]: Entering directory 
> `/home/cartman/WS/xerces-c-src_2_5_0/src/xercesc/dom/impl'
> mkdir -p /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/dom/impl
> cp -fp  DOMDeepNodeListPool.c 
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/dom/impl
> g++ -fPIC -DLINUX -D_REENTRANT -c 
> -I/home/cartman/WS/xerces-c-src_2_5_0/include -g -O2   -o 
> /home/cartman/WS/xerces-c-src_2_5_0/obj/LINUX/DOMAttrImpl.o DOMAttrImpl.cpp
> In file included from 
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.hpp:221,
>  from DOMDocumentImpl.hpp:73,
>  from DOMAttrImpl.hpp:77,
>  from DOMAttrImpl.cpp:64:
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c: In 
> constructor `xercesc_2_5::RefArrayOf::RefArrayOf(unsigned int, 
> xercesc_2_5::MemoryManager*)':
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c:111: 
> error: invalid use of undefined type `struct xercesc_2_5::MemoryManager'
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/XMemory.hpp:70: 
> error: forward declaration of `struct xercesc_2_5::MemoryManager'
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c: In 
> constructor `xercesc_2_5::RefArrayOf::RefArrayOf(TElem**, unsigned 
> int, xercesc_2_5::MemoryManager*)':
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c:125: 
> error: invalid use of undefined type `struct xercesc_2_5::MemoryManager'
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/XMemory.hpp:70: 
> error: forward declaration of `struct xercesc_2_5::MemoryManager'
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c: In 
> copy constructor `xercesc_2_5::RefArrayOf::RefArrayOf(const 
> xercesc_2_5::RefArrayOf&)':
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c:137: 
> error: invalid use of undefined type `struct xercesc_2_5::MemoryManager'
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/XMemory.hpp:70: 
> error: forward declaration of `struct xercesc_2_5::MemoryManager'
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c: In 
> destructor `xercesc_2_5::RefArrayOf::~RefArrayOf()':
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c:144: 
> error: invalid use of undefined type `struct xercesc_2_5::MemoryManager'
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/XMemory.hpp:70: 
> error: forward declaration of `struct xercesc_2_5::MemoryManager'
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c: In 
> member function `xercesc_2_5::RefArrayOf& 
> xercesc_2_5::RefArrayOf::operator=(const 
> xercesc_2_5::RefArrayOf&)':
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c:176: 
> error: invalid use of undefined type `struct xercesc_2_5::MemoryManager'
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/XMemory.hpp:70: 
> error: forward declaration of `struct xercesc_2_5::MemoryManager'
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c:178: 
> error: invalid use of undefined type `struct xercesc_2_5::MemoryManager'
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/XMemory.hpp:70: 
> error: forward declaration of `struct xercesc_2_5::MemoryManager'
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c: In 
> member function `void xercesc_2_5::RefArrayOf::resize(unsigned int)':
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c:276: 
> error: invalid use of undefined type `struct xercesc_2_5::MemoryManager'
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/XMemory.hpp:70: 
> error: forward declaration of `struct xercesc_2_5::MemoryManager'
> /home/cartman/WS/xerces-c-src_2_5_0/

[jira] [Resolved] (XERCESC-2031) Janitor::~Janitor() throws in unwind

[Alberto Massari (JIRA)]

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

Alberto Massari resolved XERCESC-2031.
--

   Resolution: Fixed
Fix Version/s: 3.2.0
 Assignee: Alberto Massari

A fix is in SVN. Pplease verify.

> Janitor::~Janitor() throws in unwind
> 
>
> Key: XERCESC-2031
> URL: https://issues.apache.org/jira/browse/XERCESC-2031
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 3.1.1
> Environment: Solaris 10, x86 
>Reporter: Jimmie Högklint
>    Assignee: Alberto Massari
> Fix For: 3.2.0
>
>
> If PosixFileMgr::fileClose() receives an invalid file handler or if its 
> unable to close a file handler it will throw an exception. If this is done in 
> an unwind of, for example, Janitor noone is around to catch 
> that exception before the process is terminated. (Leaving a destructor with a 
> throw during unwind is rewarded with termination of the process)
> This happens when variable "streamJanitor" goes out of scope in 
> ReaderMgr::createReader(...)
> Callstack looks like this:
> [6] std::terminate(0xfeafd2e3, 0xfe7eb940, 0xfc5c5ce8, 0xfe7eb940, 0x0, 
> 0xfe7eb940), at 0xfe7d471f
> [7] __Cimpl::ex_terminate(0xfedf9290, 0xfee69fd0, 0x2, 0xfe7ec658, 
> 0xfe7ec4a0, 0x0), at 0xfe7d4b82
> [8] _ex_throw_body(0xfe7ec658, 0xfeafd2e3, 0xfc5c5d60, 0xfe7d546e), at 
> 0xfe7d5561
> [9] __Crun::ex_throw(0xfe7ec6a4, 0xfed84ab8, 0xfeb04488, 0xfed82da2), at 
> 0xfe7d54ca
> [10] xercesc_3_1::PosixFileMgr::fileClose(this = 0x8f69a18, f = 0xfe3f2d00, 
> manager = 0x8f69618) (optimized), at 0xfed82e40 (line ~81) in 
> "PosixFileMgr.cpp"
> [11] xercesc_3_1::XMLPlatformUtils::closeFile(theFile = 0xfe3f2d00, memmgr = 
> 0x8f69618) (optimized), at 0xfeb021b9 (line ~578) in "PlatformUtils.cpp"
> [12] xercesc_3_1::BinFileInputStream::~BinFileInputStream(this = 0x91df400) 
> (optimized), at 0xfeafd2de (line ~64) in "BinFileInputStream.cpp"
> [13] __SLIP.DELETER__A(this = 0x91df400, delete = 1) (optimized), at 
> 0xfeafd53e (line ~61) in "BinFileInputStream.cpp"
> [14] xercesc_3_1::Janitor::reset(this = 
> 0xfc5c5e84, p = (nil)) (optimized), at 0xfec16fd6 (line ~90) in "Janitor.c"
> [15] xercesc_3_1::Janitor::~Janitor(this = 
> 0xfc5c5e84) (optimized), at 0xfec166f8 (line ~43) in "Janitor.c"
> [16] xercesc_3_1::ReaderMgr::createReader(this = 0x930a604, src = CLASS, 
> _ARG3 = true, refFrom = RefFrom_NonLiteral, type = Type_General, source = 
> Source_External, calcSrcOfs = false, lowWaterMark = 100U) (optimized), at 
> 0xfec12ee4 (line ~440) in "ReaderMgr.cpp"
> [17] xercesc_3_1::IGXMLScanner::scanReset(this = 0x930a578, src = CLASS) 
> (optimized), at 0xfec08e7c (line ~1275) in "IGXMLScanner2.cpp"
> [18] xercesc_3_1::IGXMLScanner::scanDocument(this = 0x930a578, src = CLASS) 
> (optimized), at 0xfebfb52e (line ~198) in "IGXMLScanner.cpp"
> [19] xercesc_3_1::AbstractDOMParser::parse(this = 0xfc5c6018, source = CLASS) 
> (optimized), at 0xfec67c34 (line ~545) in "AbstractDOMParser.cpp"
> [20] xercesc_3_1::IGXMLScanner::resolveSchemaGrammar(this = 0x9283f68, loc = 
> 0x93c4b3c, uri = 0x93c5020, ignoreLoadSchema = true) (optimized), at 
> 0xfec0a8d0 (line ~1859) in "IGXMLScanner2.cpp"
> [21] xercesc_3_1::IGXMLScanner::parseSchemaLocation(this = 0x9283f68, 
> schemaLocationStr = 0x9627e10, ignoreLoadSchema = true) (optimized), at 
> 0xfec0a0b4 (line ~1727) in "IGXMLScanner2.cpp"
> [22] xercesc_3_1::IGXMLScanner::scanStartTagNS(this = 0x9283f68, gotData = 
> true) (optimized), at 0xfebff71a (line ~2205) in "IGXMLScanner.cpp"
> [23] xercesc_3_1::IGXMLScanner::scanContent(this = 0x9283f68) (optimized), at 
> 0xfebfcb7b (line ~890) in "IGXMLScanner.cpp"
> [24] xercesc_3_1::IGXMLScanner::scanDocument(this = 0x9283f68, src = CLASS) 
> (optimized), at 0xfebfb571 (line ~217) in "IGXMLScanner.cpp"
> [25] xercesc_3_1::AbstractDOMParser::parse(this = 0x92e6e50, source = CLASS) 
> (optimized), at 0xfec67c34 (line ~545) in "AbstractDOMParser.cpp"
> [26] xercesc_3_1::DOMLSParserImpl::parse(this = 0x92e6e50, source = 
> 0xfc5c6718) (optimized), at 0xfec714ce (line ~754) in "DOMLSParserImpl.cpp"
> This applies to WindowsFileMgr as well.
> If additional information is needed I'm happy to provide it.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Commented] (XERCESC-1235) Xerces-C++ does not build with gcc 3.4.0

[Alberto Massari (JIRA)]

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

Alberto Massari commented on XERCESC-1235:
--

What version are you trying to compile? 2.5? Can you paste the output of your 
compiler? 

> Xerces-C++ does not build with gcc 3.4.0
> 
>
> Key: XERCESC-1235
> URL: https://issues.apache.org/jira/browse/XERCESC-1235
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 2.5.0
> Environment: Gcc 3.4.0
> Slackware GNU/Linux 10.0  
>Reporter: ismail dönmez
>
> When trying to build xerces-c with gcc 3.4.0 I get error :
> make -C impl
> make[2]: Entering directory 
> `/home/cartman/WS/xerces-c-src_2_5_0/src/xercesc/dom/impl'
> mkdir -p /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/dom/impl
> cp -fp  DOMDeepNodeListPool.c 
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/dom/impl
> g++ -fPIC -DLINUX -D_REENTRANT -c 
> -I/home/cartman/WS/xerces-c-src_2_5_0/include -g -O2   -o 
> /home/cartman/WS/xerces-c-src_2_5_0/obj/LINUX/DOMAttrImpl.o DOMAttrImpl.cpp
> In file included from 
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.hpp:221,
>  from DOMDocumentImpl.hpp:73,
>  from DOMAttrImpl.hpp:77,
>  from DOMAttrImpl.cpp:64:
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c: In 
> constructor `xercesc_2_5::RefArrayOf::RefArrayOf(unsigned int, 
> xercesc_2_5::MemoryManager*)':
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c:111: 
> error: invalid use of undefined type `struct xercesc_2_5::MemoryManager'
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/XMemory.hpp:70: 
> error: forward declaration of `struct xercesc_2_5::MemoryManager'
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c: In 
> constructor `xercesc_2_5::RefArrayOf::RefArrayOf(TElem**, unsigned 
> int, xercesc_2_5::MemoryManager*)':
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c:125: 
> error: invalid use of undefined type `struct xercesc_2_5::MemoryManager'
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/XMemory.hpp:70: 
> error: forward declaration of `struct xercesc_2_5::MemoryManager'
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c: In 
> copy constructor `xercesc_2_5::RefArrayOf::RefArrayOf(const 
> xercesc_2_5::RefArrayOf&)':
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c:137: 
> error: invalid use of undefined type `struct xercesc_2_5::MemoryManager'
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/XMemory.hpp:70: 
> error: forward declaration of `struct xercesc_2_5::MemoryManager'
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c: In 
> destructor `xercesc_2_5::RefArrayOf::~RefArrayOf()':
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c:144: 
> error: invalid use of undefined type `struct xercesc_2_5::MemoryManager'
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/XMemory.hpp:70: 
> error: forward declaration of `struct xercesc_2_5::MemoryManager'
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c: In 
> member function `xercesc_2_5::RefArrayOf& 
> xercesc_2_5::RefArrayOf::operator=(const 
> xercesc_2_5::RefArrayOf&)':
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c:176: 
> error: invalid use of undefined type `struct xercesc_2_5::MemoryManager'
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/XMemory.hpp:70: 
> error: forward declaration of `struct xercesc_2_5::MemoryManager'
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c:178: 
> error: invalid use of undefined type `struct xercesc_2_5::MemoryManager'
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/XMemory.hpp:70: 
> error: forward declaration of `struct xercesc_2_5::MemoryManager'
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c: In 
> member function `void xercesc_2_5::RefArrayOf::resize(unsigned int)':
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/RefArrayOf.c:276: 
> error: invalid use of undefined type `struct xercesc_2_5::MemoryManager'
> /home/cartman/WS/xerces-c-src_2_5_0/include/xercesc/util/XMemory.hpp:70: 
> error: forward declaration of `struct xercesc_2_5::MemoryManager'
> /home/cartman/WS/xerces

[jira] [Resolved] (XERCESC-2030) failed to do validation when there's Japanese words in the xml file

[Alberto Massari (JIRA)]

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

Alberto Massari resolved XERCESC-2030.
--

Resolution: Not a Problem

Your code is doing a dangerous thing: using XMLString::trascode in the SAX 
callback. This tries to convert a Unicode string into a locale that you cannot 
control and that, in your case, is unable to represent non-European characters. 
If you really need to store non-Unicode strings in a stack, please convert them 
into UTF-8, and never use XMLString::transcode, unless you are preparing to 
print data to the console

> failed to do validation when there's Japanese words in the xml file
> ---
>
> Key: XERCESC-2030
> URL: https://issues.apache.org/jira/browse/XERCESC-2030
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: SAX/SAX2
> Environment: SunOS 5.10 Generic_139555-08 sun4u sparc 
> SUNW,Sun-Fire-V245
> xerces C++ 3.1.1
>Reporter: ocean_helen
>
> Hi owners,
>  I got a problem when using Xerces C++ 3.1.1 to do schema validation 
> which has Japanese words in the xml file.  it raised FatalError: invalid 
> multi-byte sequence and stop validation.
>  Environment: Linux
>  Locale:
> LANG=
> LC_CTYPE=en_GB.ISO8859-1
> LC_NUMERIC=C
> LC_TIME=en_GB.ISO8859-1
> LC_COLLATE=en_GB.ISO8859-1
> LC_MONETARY=en_GB.ISO8859-1
> LC_MESSAGES=C
> LC_ALL=
> The xml file is generated in linux and because of the business, we 
> couldn't change characterset from ISO8859-1 to UTF-8 from the system side, so 
> do we have any workaround to skip this kind of error,  or is it possible to 
> modify characterset to pass the validation in C++?
>  All the source codes are attached at below, please let me know if you 
> need any more information.
>  Looking forward to your reply and thank you so much in advance.
> Source Code: 
> a.xsd:
> 
> 
> http://www.w3.org/2001/XMLSchema";>
>  
> 
>   
> 
>   
> 
>   
> 
>   
> 
>   
> 
>  
> 
> a.xml:
> 
> 
> http://www.w3.org/2001/XMLSchema-instance";
> xsi:noNamespaceSchemaLocation=
> "gobitan.xsd">
>  
> 円短期
> 
> 
> val.cpp
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include "MyHandler.hpp"
> #if defined(XERCES_NEW_IOSTREAMS)
> #include 
> #else
> #include 
> #endif
> using namespace std;
> using namespace xercesc;
> //XERCES_CPP_NAMESPACE_USE
> int main( int argc , char** argv )
> {
>XMLPlatformUtils::Initialize(); //.
>SAX2XMLReader* parser = XMLReaderFactory::createXMLReader();
>parser->setFeature(XMLUni::fgSAX2CoreNameSpaces, true);
> parser->setFeature(XMLUni::fgSAX2CoreNameSpacePrefixes, true);
>parser->setFeature(XMLUni::fgXercesValidationErrorAsFatal, true);
>parser->setFeature(XMLUni::fgSAX2CoreValidation, true);
> parser->setFeature(XMLUni::fgXercesSchema, true);
> parser->setFeature(XMLUni::fgXercesSchemaFullChecking, true);
> parser->setFeature(XMLUni::fgXercesLoadSchema,true);
> parser->setExitOnFirstFatalError(false);
>  parser->loadGrammar ("a.xsd", Grammar::SchemaGrammarType, true);
> MyHandler* handler=new MyHandler();
> parser->setContentHandler(handler);
> parser->setErrorHandler(handler);
>try
>{
>parser->parse("a.xml");
> vector errs=handler->getSchemaErrorContent();
> if(errs.size()>0)
> {
> cout<<"ERROR MESSAGE OF SCHEMA VALIDATION="< for (unsigned int i = 0; i < errs.size();i++)
> {
> cout< }
> }
> cout<<"END TRY"<  }
> catch (const XMLException& toCatch) {
> char* message = XMLString::transcode(toCatch.getMessage());
> cout << "Exception message is: \n"
>  << message << "\n";
> XMLString::release(&message);
> return -1;
> }
> catch (const SAXParseException& toCatch) {
> char* message = XMLString::transcode(toCatch.getMessage

[jira] [Resolved] (XERCESC-2028) Curl Checking

[Alberto Massari (JIRA)]

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

Alberto Massari resolved XERCESC-2028.
--

   Resolution: Fixed
Fix Version/s: 3.2.0
 Assignee: Alberto Massari

Fix is in SVN

> Curl Checking
> -
>
> Key: XERCESC-2028
> URL: https://issues.apache.org/jira/browse/XERCESC-2028
> Project: Xerces-C++
>  Issue Type: Bug
>Affects Versions: 3.1.1
> Environment: mingw
>Reporter: Zane U. Ji
>Assignee: Alberto Massari
> Fix For: 3.2.0
>
> Attachments: xerces_curl_prefix.m4.patch
>
>
> The problem is quite similar to the one reported at 
> https://issues.apache.org/jira/browse/XERCESC-2006
> configure can't find the CURL library installed on the system.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Commented] (XERCESC-2029) The schema URL support doesn't support

[Alberto Massari (JIRA)]

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

Alberto Massari commented on XERCESC-2029:
--

The different options are listed at 
http://xerces.apache.org/xerces-c/build-3.html
The default choice is "plain socket", and that only supports very simple HTTP 
requests

> The schema URL support doesn't support
> --
>
> Key: XERCESC-2029
> URL: https://issues.apache.org/jira/browse/XERCESC-2029
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Validating Parser (XML Schema)
>Affects Versions: 3.1.0
>Reporter: Alexandru Stefanescu
>  Labels: patch
> Fix For: 3.1.0
>
>
> When the input file has 'schemaLocation' with an URL like :
> https://aarembargo.railinc.com/epdb/xsd/Embargo.xsd (the https is the issue) 
> then xerces throws this fatal error Message: "unsupported protocol in URL".
> This is blocking our product to parse/validate XML files received from 
> another party which have these URL's.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Resolved] (XERCESC-2029) The schema URL support doesn't support

[Alberto Massari (JIRA)]

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

Alberto Massari resolved XERCESC-2029.
--

Resolution: Not a Problem

The default, built-in NetAccessor doesn't support https protocol. You will have 
to build the sources specifying the cURL or the Winsock accessor

> The schema URL support doesn't support
> --
>
> Key: XERCESC-2029
> URL: https://issues.apache.org/jira/browse/XERCESC-2029
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Validating Parser (XML Schema)
>Affects Versions: 3.1.0
>Reporter: Alexandru Stefanescu
>  Labels: patch
> Fix For: 3.1.0
>
>
> When the input file has 'schemaLocation' with an URL like :
> https://aarembargo.railinc.com/epdb/xsd/Embargo.xsd (the https is the issue) 
> then xerces throws this fatal error Message: "unsupported protocol in URL".
> This is blocking our product to parse/validate XML files received from 
> another party which have these URL's.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Resolved] (XERCESC-2026) typo in validators ContentSpecNode::getMaxTotalRange()

[Alberto Massari (JIRA)]

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

Alberto Massari resolved XERCESC-2026.
--

Resolution: Duplicate

Duplicate of XERCESC-1994

> typo in validators ContentSpecNode::getMaxTotalRange()
> --
>
> Key: XERCESC-2026
> URL: https://issues.apache.org/jira/browse/XERCESC-2026
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Validating Parser (XML Schema)
>Affects Versions: 3.2.0
> Environment: Windows 7 64
>Reporter: Maks Naumov
>Priority: Minor
>
> .\src\xercesc\validators\common\ContentSpecNode.cpp 262
> I think here the error.
> max = max * (maxFirst > maxSecond) ? maxFirst : maxSecond;
> '?' operator has lower priority than '*'
> Must be:
> max = max * (maxFirst > maxSecond ? maxFirst : maxSecond);



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Commented] (XERCESC-2019) Error in memory allocation for even small messages.

[Alberto Massari (JIRA)]

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

Alberto Massari commented on XERCESC-2019:
--

There is the limitation of the memory required to keep the data in memory; 
there is the overhead of the DOM nodes, and the data of the XML is kept in 
Unicode format, so assuming your XML is almost entirely a single text node, at 
a certain point you could have allocated the 179Mb*sizeof(XMLCh) of the 
previous buffer plus a 2*179Mb*sizeof(XMLCh) new buffer, that is more than 1Gb 
of memory

> Error in memory allocation for even small messages.
> ---
>
> Key: XERCESC-2019
> URL: https://issues.apache.org/jira/browse/XERCESC-2019
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: DOM
>Affects Versions: 3.1.1
> Environment: windows XP vc9, linux and solaris
>Reporter: mahalakshmi
>Assignee: Alberto Massari
>  Labels: patch
> Fix For: 3.2.0
>
> Attachments: zippedfiles.zip
>
>
> I have my xsd schema using which i have created my standard xml.
> After creating the xml i fill the values for each tag in my xml. 
> I get memory allocation error when i try to traverse through the xml and set 
> the values for each tag in my xml.
> I get allocation error when my program calls the setTextcontent() of 
> xerces.It is crashing in DOMDocumentImpl.cpp allocate(size).(2nd if condition 
> in that function)
> Is there any setting that needs to be done for memory allocation? How much is 
> the maximum size of xml that xerces can parse?how do we manage the memory 
> allocation and deallocation in DOM?



--
This message was sent by Atlassian JIRA
(v6.1#6144)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Resolved] (XERCESC-2015) Fix warnings under g++ 4.7.2 with -Wall

[Alberto Massari (JIRA)]

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

Alberto Massari resolved XERCESC-2015.
--

Resolution: Won't Fix

Version 2.8 is not maintained anymore, and the current 3.1 code base already 
has these fixes in

> Fix warnings under g++ 4.7.2 with -Wall
> ---
>
> Key: XERCESC-2015
> URL: https://issues.apache.org/jira/browse/XERCESC-2015
> Project: Xerces-C++
>  Issue Type: Improvement
>  Components: Validating Parser (XML Schema)
>Affects Versions: 2.8.0
>Reporter: Mike Giroux
>Priority: Minor
> Fix For: 2.8.0
>
> Attachments: xercesc-2015.patch
>
>
> SchemaAttDef.hpp and SchemaElementDecl.hpp both trigger warnings under -Wall 
> with g++ 4.7.2.  In our environment, since we use -Werror for validation, 
> these become a more serious issue.
> There are 2 categories of fixes - a signed/unsigned comparison mismatch in 
> SchemaElementDecl::isGlobalDecl, and some missing parens in if statements in 
> SchemaAttDef::getMemberTypeAnonymous() and bool 
> SchemaElementDecl::isTypeDefinitionUnion().
> Here's a patch:
> ---
>  src/xercesc/validators/schema/SchemaAttDef.hpp  | 4 ++--
>  src/xercesc/validators/schema/SchemaElementDecl.hpp | 6 +++---
>  2 files changed, 5 insertions(+), 5 deletions(-)
> diff --git a/src/xercesc/validators/schema/SchemaAttDef.hpp 
> b/src/xercesc/validators/schema/SchemaAttDef.hpp
> index 7648de0..2c069b7 100644
> --- a/src/xercesc/validators/schema/SchemaAttDef.hpp
> +++ b/src/xercesc/validators/schema/SchemaAttDef.hpp
> @@ -401,8 +401,8 @@ inline bool SchemaAttDef::getMemberTypeAnonymous() const {
>  }
>  inline bool SchemaAttDef::isTypeDefinitionUnion() const {
> -   if(fAnyDatatypeValidator && fAnyDatatypeValidator->getType() == 
> DatatypeValidator::Union ||
> -  fDatatypeValidator && fDatatypeValidator->getType() == 
> DatatypeValidator::Union)
> +   if(   (fAnyDatatypeValidator && fAnyDatatypeValidator->getType() == 
> DatatypeValidator::Union)
> +  || (fDatatypeValidator && fDatatypeValidator->getType() == 
> DatatypeValidator::Union))
> return true;
>  return false;
>  }
> diff --git a/src/xercesc/validators/schema/SchemaElementDecl.hpp 
> b/src/xercesc/validators/schema/SchemaElementDecl.hpp
> index 9ffc2f2..5f9ad8f 100644
> --- a/src/xercesc/validators/schema/SchemaElementDecl.hpp
> +++ b/src/xercesc/validators/schema/SchemaElementDecl.hpp
> @@ -506,7 +506,7 @@ inline SchemaAttDef* SchemaElementDecl::getAttWildCard() {
>  inline bool SchemaElementDecl::isGlobalDecl() const {
> -return (fEnclosingScope == Grammar::TOP_LEVEL_SCOPE);
> +return (static_cast(fEnclosingScope) == 
> Grammar::TOP_LEVEL_SCOPE);
>  }
>  inline SchemaElementDecl*
> @@ -591,8 +591,8 @@ inline bool SchemaElementDecl::getMemberTypeAnonymous() 
> const {
>  inline bool SchemaElementDecl::isTypeDefinitionUnion() const {
>  // removing fXsi* references would break DOMTypeInfo implementation 
> completely;
>  // will have to wait for now
> -   if(fXsiSimpleTypeInfo && fXsiSimpleTypeInfo->getType() == 
> DatatypeValidator::Union ||
> -  fDatatypeValidator && fDatatypeValidator->getType() == 
> DatatypeValidator::Union)
> +   if(   (fXsiSimpleTypeInfo && fXsiSimpleTypeInfo->getType() == 
> DatatypeValidator::Union)
> +  || (fDatatypeValidator && fDatatypeValidator->getType() == 
> DatatypeValidator::Union))
> return true;
>  return false;
>  }
> --



--
This message was sent by Atlassian JIRA
(v6.1#6144)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Closed] (XERCESC-2022) README and INSTALL files contain non-existing link

[Alberto Massari (JIRA)]

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

Alberto Massari closed XERCESC-2022.


Resolution: Not A Problem

The README and INSTALL files are using the references to the documentation that 
is shipped with the product in the binary releases. If you download the SVN 
trunk you should use http://xerces.apache.org/xerces-c/build-3.html to get the 
correct instructions for building the product

> README and INSTALL files contain non-existing link
> --
>
> Key: XERCESC-2022
> URL: https://issues.apache.org/jira/browse/XERCESC-2022
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 3.1.0
> Environment: ubuntu 12.04LTS
>Reporter: jan iversen
>Priority: Minor
>
> I downloaded Xerces C trunk, and wanted to find how to install it.
> file INSTALL and file README in /xerces/c/trunk ask me to:
> "See doc/html/index.html for installation instructions and other
> relevant documentation."
> but doc/html does not contain a index.html or anything else that look like 
> installation options.
> rgds
> jani



--
This message was sent by Atlassian JIRA
(v6.1#6144)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Resolved] (XERCESC-2023) Use icu, which is built with features

[Alberto Massari (JIRA)]

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

Alberto Massari resolved XERCESC-2023.
--

   Resolution: Fixed
Fix Version/s: 3.2.0
 Assignee: Alberto Massari

> Use icu, which is built with features
> -
>
> Key: XERCESC-2023
> URL: https://issues.apache.org/jira/browse/XERCESC-2023
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 3.1.1
>Reporter: Aleksey Dobrunov
>Assignee: Alberto Massari
>  Labels: icu, patch
> Fix For: 3.2.0
>
> Attachments: ICUTransService.cpp.diff
>
>
> if the library 'icu' compiled with the flag U_NO_DEFAULT_INCLUDE_UTF_HEADERS 
> (http://source.icu-project.org/repos/icu/icu/trunk/readme.html#RecBuild), 
> then build 'xercesc' fails.
>  attached patche solve these problem



--
This message was sent by Atlassian JIRA
(v6.1#6144)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Resolved] (XERCESC-2024) LocalFileFormatTarget leaks file handle

[Alberto Massari (JIRA)]

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

Alberto Massari resolved XERCESC-2024.
--

   Resolution: Fixed
Fix Version/s: 3.2.0
 Assignee: Alberto Massari

A fix is in SVN. Please verify.

> LocalFileFormatTarget leaks file handle
> ---
>
> Key: XERCESC-2024
> URL: https://issues.apache.org/jira/browse/XERCESC-2024
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Miscellaneous
>Reporter: Vemund Handeland
>    Assignee: Alberto Massari
> Fix For: 3.2.0
>
> Attachments: LocalFileFormatTarget.cpp.patch
>
>
> The call to XMLPlatformUtils::writeBufferToFile in the LocalFileFormatTarget 
> destructor might throw an exception. A typical use case is running out of 
> disk space.
> In this case the file handle will not be closed



--
This message was sent by Atlassian JIRA
(v6.1#6144)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Commented] (XERCESC-2019) Error in memory allocation for even small messages.

[Alberto Massari (JIRA)]

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

Alberto Massari commented on XERCESC-2019:
--

You need to get the current trunk of the repository from 
https://svn.apache.org/repos/asf/xerces/c/trunk

> Error in memory allocation for even small messages.
> ---
>
> Key: XERCESC-2019
> URL: https://issues.apache.org/jira/browse/XERCESC-2019
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: DOM
>Affects Versions: 3.1.1
> Environment: windows XP vc9, linux and solaris
>Reporter: mahalakshmi
>Assignee: Alberto Massari
>  Labels: patch
> Fix For: 3.2.0
>
> Attachments: zippedfiles.zip
>
>
> I have my xsd schema using which i have created my standard xml.
> After creating the xml i fill the values for each tag in my xml. 
> I get memory allocation error when i try to traverse through the xml and set 
> the values for each tag in my xml.
> I get allocation error when my program calls the setTextcontent() of 
> xerces.It is crashing in DOMDocumentImpl.cpp allocate(size).(2nd if condition 
> in that function)
> Is there any setting that needs to be done for memory allocation? How much is 
> the maximum size of xml that xerces can parse?how do we manage the memory 
> allocation and deallocation in DOM?



--
This message was sent by Atlassian JIRA
(v6.1#6144)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Resolved] (XERCESC-1988) memory leak DOMBuffer::expandCapacity

[Alberto Massari (JIRA)]

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

Alberto Massari resolved XERCESC-1988.
--

Resolution: Duplicate

Duplicate of XERCESC-2019

> memory leak DOMBuffer::expandCapacity
> -
>
> Key: XERCESC-1988
> URL: https://issues.apache.org/jira/browse/XERCESC-1988
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: DOM
>Affects Versions: 3.1.0
> Environment: all
>Reporter: Reinier vos
>
> in  src/xercesc/dom/impl/DOMStringPool.cpp
> DOMBuffer::expandCapacity
> a new buffer of the required size is created while leaving the original 
> buffer in memory (comented as a know issue). This posses serious memory 
> issues for large strings ( e.g. base64 strings). Creating a text node of 60MB 
> requires like 600MB memory.
> I poked a little change in the mentioned function which by no means is a neat 
> way but for this application it does the trick (and it describes the issue):
>  // Copy over the old stuff
> memcpy(newBuf, fBuffer, fCapacity * sizeof(XMLCh));
>   // in DOMDocumentImpl::allocate a standard block 
> (header+buffer[kHeapAllocSize]) is used for allocations <= 
> kMaxSubAllocationSize
>   // Anything bigger is put into its own block (with its own buffer[cap])
>   // Check if the buffer we expaned was in its own block, this can be 
> deleted safely after a reallocate
>   if ( fCapacity * sizeof(XMLCh) > 4096 )
>   {
>   size_t sizeOfHeader = 
> XMLPlatformUtils::alignPointerForNewBlockAllocation(sizeof(void *));
>   //retrieve the location of the buffer preceding the one we're 
> about to delete
>   //set this location in the new header 
>   *(void **)( (char *)newBuf-sizeOfHeader )=*(void **)( (char 
> *)fBuffer-sizeOfHeader );
>   delete(((char *)fBuffer-sizeOfHeader));
>   }
> // store new stuff
> fBuffer = newBuf;
> fCapacity = newCap;



--
This message was sent by Atlassian JIRA
(v6.1#6144)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Resolved] (XERCESC-2019) Error in memory allocation for even small messages.

[Alberto Massari (JIRA)]

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

Alberto Massari resolved XERCESC-2019.
--

   Resolution: Fixed
Fix Version/s: (was: 3.1.1)
   3.2.0
 Assignee: Alberto Massari

Xerces has always been conservative with the memory it had allocated, i.e. it 
never deallocated the memory of a DOMText node when an append() was called, to 
avoid crashing the client code that had retrieved the previous pointer via a 
call to getNodeValue(). In your case this implied allocating a lot of 
intermediate memory blocks before the 250Mb needed by your Base64 string were 
finally allocated. I have checked in a workaround that allows the parser (and 
only the parser) to deallocate them. 

> Error in memory allocation for even small messages.
> ---
>
> Key: XERCESC-2019
> URL: https://issues.apache.org/jira/browse/XERCESC-2019
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: DOM
>Affects Versions: 3.1.1
> Environment: windows XP vc9, linux and solaris
>Reporter: mahalakshmi
>    Assignee: Alberto Massari
>  Labels: patch
> Fix For: 3.2.0
>
> Attachments: zippedfiles.zip
>
>
> I have my xsd schema using which i have created my standard xml.
> After creating the xml i fill the values for each tag in my xml. 
> I get memory allocation error when i try to traverse through the xml and set 
> the values for each tag in my xml.
> I get allocation error when my program calls the setTextcontent() of 
> xerces.It is crashing in DOMDocumentImpl.cpp allocate(size).(2nd if condition 
> in that function)
> Is there any setting that needs to be done for memory allocation? How much is 
> the maximum size of xml that xerces can parse?how do we manage the memory 
> allocation and deallocation in DOM?



--
This message was sent by Atlassian JIRA
(v6.1#6144)

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Resolved] (XERCESC-2016) XML 1.0 5th edition support

[Alberto Massari (JIRA)]

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

Alberto Massari resolved XERCESC-2016.
--

   Resolution: Fixed
Fix Version/s: (was: 3.1.2)
   3.2.0
 Assignee: Alberto Massari

I have gone through the 5th edition specs and implemented a good part of it; 
the XML Test suite still reports 16 failures mainly due to URI rules

> XML 1.0 5th edition support
> ---
>
> Key: XERCESC-2016
> URL: https://issues.apache.org/jira/browse/XERCESC-2016
> Project: Xerces-C++
>  Issue Type: Improvement
>  Components: Non-Validating Parser
>Affects Versions: 3.1.1
> Environment: All
>Reporter: Rob Cameron
>    Assignee: Alberto Massari
> Fix For: 3.2.0
>
> Attachments: diff5e
>
>
> Xerces-C currently applies XML 1.0 4th edition rules to name characters
> in XML 1.0 documents.XML 1.0 5th edition permits a broader class
> of name characters, based on those permitted in XML 1.1.
> Proposal: that Xerces-C 3.2.0 be updated to include support for XML 1.0
> 5th edition.
> Although our main work is with icXML, we've looked at making this change
> in Xerces-C original code base so that icXML support for XML 1.0 5e is
> compatible with us.
> I'm not entirely sure that I've handled everything, but the following change
> works in our test.  The change plan is below and a svn diff file is
> attached.
> Here is the change plan.
> --
> (1)  internal/CharTypeTables.hpp
> Rename gFirstNameChars1_1 to be gFirstNameChars
> Rename gNameChars1_1 to be gNameChars
> (2) util/XMLChar.cpp
> (2a)
>Update initCharFlagTable1_1() to use the gFirstNameChars, gNameChars
>Update initCharFlagTable() to use the set-ups from initCharFlagTable1_1()
>  to define gNameCharMask, gNCNameCharMask, and gFirstNameCharMask.
> //
> //  Name characters are special. A name is made up of a number of
> //  different tables and some special case characters.
> //
> initOneTable(gNameChars, gNameCharMask);
> //
> //  Name characters are special. A name is made up of a number of
> //  different tables and some special case characters.
> //
> initOneTable(gNameChars, gNCNameCharMask);
> gTmpCharTable[chColon] &= ~gNCNameCharMask;
> //
> //  Then do the first name char
> //
> initOneTable(gFirstNameChars, gFirstNameCharMask);
> (2b) #define NEED_TO_GEN_TABLE
> compile and do a sample run of a Xerces app, generate table.out
> (2c) Replace the XMLChar1_0::fgCharCharsTable1_0 definition pf XMLChar.cpp
> with that from table.out.
> (3) XMLChar.hpp
> Modify XMLChar1_0::isFirstNameChar, XMLChar1_0::isFirstNCNameChar,
> XMLChar1_0::isNameChar, XMLChar1_0::isNCNameChar
> to each check for and allow characters in the #x1-#xE range
> else {
> if ((toCheck >= 0xD800) && (toCheck <= 0xDB7F))
>if ((toCheck2 >= 0xDC00) && (toCheck2 <= 0xDFFF))
>return true;
> }
> (4)  Modify XMLReader::getName and XMLReader::getNCName
>to allow surrogate pairs in Names and NCNames
>(i.e., use the version 1.1 logic for both 1.0 and 1.1).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Resolved] (XERCESC-2017) Xerces-C++ is not always able to handle W3C standard keyref

[Alberto Massari (JIRA)]

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

Alberto Massari resolved XERCESC-2017.
--

   Resolution: Fixed
Fix Version/s: 3.2.0
 Assignee: Alberto Massari

A fix is in SVN. Please verify

> Xerces-C++ is not always able to handle W3C standard keyref
> ---
>
> Key: XERCESC-2017
> URL: https://issues.apache.org/jira/browse/XERCESC-2017
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Validating Parser (XML Schema)
>Affects Versions: 3.1.1
>Reporter: Mihran Hovsepyan
>Assignee: Alberto Massari
> Fix For: 3.2.0
>
>
> I use *Xerces-C++ 3.1.1* to validate schema of xml files. Bellow is example 
> of some such file.
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
> And in its schema the following key and keyref are defined for the root 
> element `CONFIG`.
>   
>xpath="./DBS/DB|./DBS/VDB|./DBS/VDB/PARTS/PART_DB" />
>   
>   
>   
>/>
>   
>   
> So, though the file meets requirements of the schema according to *W3C* and 
> some validators understand that (for instance XML validator of *MS Visual 
> Studio*), *Xerces-C++ 3.1.1* unable to do that. It complains:
> identity constraint key for element 'CONFIG' not found (last_line, 
> last_column_of_last_line)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Commented] (XERCESC-2019) Error in memory allocation for even small messages.

[Alberto Massari (JIRA)]

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

Alberto Massari commented on XERCESC-2019:
--

Can you attach the XML and the code that you use to populate each tag?

> Error in memory allocation for even small messages.
> ---
>
> Key: XERCESC-2019
> URL: https://issues.apache.org/jira/browse/XERCESC-2019
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: DOM
>Affects Versions: 3.1.1
> Environment: windows XP vc9, linux and solaris
>Reporter: mahalakshmi
>  Labels: patch
> Fix For: 3.1.1
>
>
> I have my xsd schema using which i have created my standard xml.
> After creating the xml i fill the values for each tag in my xml. 
> I get memory allocation error when i try to traverse through the xml and set 
> the values for each tag in my xml.
> I get allocation error when my program calls the setTextcontent() of 
> xerces.It is crashing in DOMDocumentImpl.cpp allocate(size).(2nd if condition 
> in that function)
> Is there any setting that needs to be done for memory allocation? How much is 
> the maximum size of xml that xerces can parse?how do we manage the memory 
> allocation and deallocation in DOM?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Resolved] (XERCESC-2021) pdb file extension fullpdb not compatible with symbol server

[Alberto Massari (JIRA)]

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

Alberto Massari resolved XERCESC-2021.
--

   Resolution: Fixed
Fix Version/s: 3.2.0
 Assignee: Alberto Massari

I opted for a .full.pdb extension, to keep the stripped database as the default 
PDB for release versions

> pdb file extension fullpdb not compatible with symbol server
> 
>
> Key: XERCESC-2021
> URL: https://issues.apache.org/jira/browse/XERCESC-2021
> Project: Xerces-C++
>  Issue Type: Improvement
>  Components: Build
>Affects Versions: 3.1.1
> Environment: Visual Studio
>Reporter: Vemund Handeland
>    Assignee: Alberto Massari
>Priority: Minor
> Fix For: 3.2.0
>
> Attachments: pdb_file_extension.patch
>
>
> Release builds of XercesLib creates pdb file "xerces-c_3_1.fullpdb" + 
> stripped pdb file "xerces-c_3_1.pdb".
> Full path to the first file is included in the dll, and the debugger uses 
> this information to locate the symbols. The stripped version must be renamed 
> before it can be used.
> The extension fullpdb is not compatible with Microsoft Symbol Server 
> (http://msdn.microsoft.com/en-us/library/ms680693(v=vs.85).aspx). (I've not 
> been able to add the file with symstore.exe, and the debuggers are unable to 
> fetch a copy I've manually added to my symbol server).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Resolved] (XERCESC-2020) Off-by-one error in TranscodeFromStr (with ICU)

[Alberto Massari (JIRA)]

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

Alberto Massari resolved XERCESC-2020.
--

   Resolution: Fixed
Fix Version/s: 3.2.0

A fix is in SVN. Please verify

> Off-by-one error in TranscodeFromStr (with ICU)
> ---
>
> Key: XERCESC-2020
> URL: https://issues.apache.org/jira/browse/XERCESC-2020
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 3.1.1
> Environment: ICU, Visual C++ 2012
>Reporter: Martin Raiber
>    Assignee: Alberto Massari
> Fix For: 3.2.0
>
>
> The char-Array charSizes in TranscodeFromStr::transcode is initialized with 
> length csSize.
> ICUTranscoder::transcodeFrom is called with maxChars=csSize+1.
> For a fixed length encoding charSizes is set via memset(charSizes, fillSize, 
> maxChars); writing one character too much.
> To reproduce:
> xercesc::TranscodeFromStr transcoder(reinterpret_cast("foo"), 
> 3, "ISO-8859-15");

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Assigned] (XERCESC-2020) Off-by-one error in TranscodeFromStr (with ICU)

[Alberto Massari (JIRA)]

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

Alberto Massari reassigned XERCESC-2020:


Assignee: Alberto Massari

> Off-by-one error in TranscodeFromStr (with ICU)
> ---
>
> Key: XERCESC-2020
> URL: https://issues.apache.org/jira/browse/XERCESC-2020
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 3.1.1
> Environment: ICU, Visual C++ 2012
>Reporter: Martin Raiber
>    Assignee: Alberto Massari
>
> The char-Array charSizes in TranscodeFromStr::transcode is initialized with 
> length csSize.
> ICUTranscoder::transcodeFrom is called with maxChars=csSize+1.
> For a fixed length encoding charSizes is set via memset(charSizes, fillSize, 
> maxChars); writing one character too much.
> To reproduce:
> xercesc::TranscodeFromStr transcoder(reinterpret_cast("foo"), 
> 3, "ISO-8859-15");

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: compiler defines - xercesc 2.8

[Alberto Massari]

Il 04/06/13 22:43, Huantes, Dan F (TASC) ha scritto:


Mike,

I extracted the following from the  CMakeLists.txt file I created for 
Xerces 3.1.1 for generation of Visual Studio 8,9,10, and 11 project 
files.  Might help you get started Unfortunately I didn't write 
down what they were all for...


set (Xerces_DEFINES

-DXERCES_BUILDING_LIBRARY

defined on Windows to use the proper __declspec(dllexport)/(dllimport) 
in the headers; but, if XERCES_STATIC_LIBRARY is defined, they are not 
generated as the final product is not a DLL but a LIB file


-DXERCES_USE_TRANSCODER_WINDOWS

enable the transcoder that uses the Windows APIs; other choices are 
XERCES_USE_TRANSCODER_ICU, XERCES_USE_TRANSCODER_MACOSUNICODECONVERTER, 
XERCES_USE_TRANSCODER_GNUICONV, or XERCES_USE_TRANSCODER_ICONV


-DXERCES_USE_WIN32_MSGLOADER

enable the message loader that uses the Windows  resources; other 
choices are XERCES_USE_MSGLOADER_ICU, XERCES_USE_MSGLOADER_ICONV or 
XERCES_USE_MSGLOADER_INMEMORY


-DXERCES_USE_NETACCESSOR_WINSOCK

enable the network accessor that uses the Winsock API; other choices are 
XERCES_USE_NETACCESSOR_CURL, XERCES_USE_NETACCESSOR_CFURL, or 
XERCES_USE_NETACCESSOR_SOCKET


-DXERCES_USE_FILEMGR_WINDOWS

enable the file manager for Windows file system; the other option is 
XERCES_USE_FILEMGR_POSIX


-DXERCES_USE_MUTEXMGR_WINDOWS

enable the mutex manager that uses the Windows APIs; other choices are 
XERCES_USE_MUTEXMGR_NOTHREAD and XERCES_USE_MUTEXMGR_POSIX


-DXERCES_PATH_DELIMITER_BACKSLASH


define the \ character as path separator


WITH_IPV6 enables the IPv6 addresses in the network accessor
XERCES_HAVE_SSE2_INTRINSIC enables the usage of assembly-like SIMD 
instructions to speed up processing
The HAVE_ macros define whether the compiler has a specific header 
file (limits.h, sys/timeb.h) or functions (stricmp, strnicmp..)


-DHAVE_STRICMP

-DHAVE_STRNICMP

-DHAVE_LIMITS_H

-DHAVE_SYS_TIMEB_H

-DHAVE_FTIME

-DHAVE_WCSUPR

-DHAVE_WCSLWR

-DHAVE_WCSICMP

-DHAVE_WCSNICMP

)

If XERCES_TMPLSINC is defined, the code for the templates is included in 
the header file where they are declared, otherwise they are compiled 
from a separacte C file (necessary for some very old and odd compiler)
The PROJ_ macros were used in v2.8 to include/exclude part of the 
code, e.g. excluding DOM or SAX from the built library.


Hope this helps,
Alberto

[jira] [Closed] (XERCESC-2006) build xerces-c with icu on mingw gcc 4.7.2

[Alberto Massari (JIRA)]

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

Alberto Massari closed XERCESC-2006.



> build xerces-c with icu on mingw gcc 4.7.2
> --
>
> Key: XERCESC-2006
> URL: https://issues.apache.org/jira/browse/XERCESC-2006
> Project: Xerces-C++
>  Issue Type: Bug
> Environment: mingw
> icu 5 from trunk
> xerces-c from trunk
> gcc 4.7.2
>Reporter: Aleksey Dobrunov
>Assignee: Alberto Massari
> Fix For: 3.2.0
>
> Attachments: xerces_icu_prefix.m4.diff
>
>
> i am trying build xerces-c with icu
> reconf
> ./configure --enable-transcoder-icu  --enable-msgloader-icu --disable-network 
> in the end 
> configure:21971: Report:
> configure:21973:   File Manager: Windows
> configure:21975:   Mutex Manager: Windows
> configure:21977:   Transcoder: windows
> configure:21979:   NetAccessor: disabled
> configure:21981:   Message Loader: inmemory
> in config.log 
> configure:18085: checking for ucnv_open in -licuuc
> configure:18103: g++ -o conftest.exe -O2  -mthreads -I/icu1/include
> -lpthread -lm   -L/icu1/lib -licui18n -licuuc -licudata  -lpthread -lm 
> conftest.cpp  >&5
> C:\Users\ALEKSE~1.DOB\AppData\Local\Temp\ccg1wi5K.o:conftest.cpp:(.text.startup+0x1e):
>  undefined reference to `ucnv_open_51'
> collect2.exe: error: ld returned 1 exit status
> This error occurs because conftest.cpp specified later runtime libraries on 
> which it depends.
> this command work fine
> g++ -o conftest.exe -O2  conftest.cpp -mthreads -I/icu1/include-lpthread 
> -lm   -L/icu1/lib -licui18n -licuuc -licudata  -lpthread -lm  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Resolved] (XERCESC-1998) Add support for GNU/Hurd by using POSIX.1-2001 and POSIX.1-2008 functions

[Alberto Massari (JIRA)]

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

Alberto Massari resolved XERCESC-1998.
--

   Resolution: Fixed
Fix Version/s: (was: 3.1.1)
   3.2.0
 Assignee: Alberto Massari

I added a test for PATH_MAX in the configure script. Please verify.

> Add support for GNU/Hurd by using POSIX.1-2001 and POSIX.1-2008 functions
> -
>
> Key: XERCESC-1998
> URL: https://issues.apache.org/jira/browse/XERCESC-1998
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 3.1.1
> Environment: Debian GNU/Hurd i386
>Reporter: Svante Signell
>    Assignee: Alberto Massari
>  Labels: patch
> Fix For: 3.2.0
>
> Attachments: use_posix_fcns.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Hello,
> The attached patch solves the build problems for GNU/Hurd due to 
> unconditional use of PATH_MAX which is not defined on Hurd (and is optional 
> in POSIX). The functions used are realpath (newSrc, NULL) from POSIX.1-2008 
> and getcwd (NULL, 0) from glibc-based systems.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Resolved] (XERCESC-2006) build xerces-c with icu on mingw gcc 4.7.2

[Alberto Massari (JIRA)]

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

Alberto Massari resolved XERCESC-2006.
--

   Resolution: Fixed
Fix Version/s: 3.2.0
 Assignee: Alberto Massari

The patch is in SVN. Please verify.

> build xerces-c with icu on mingw gcc 4.7.2
> --
>
> Key: XERCESC-2006
> URL: https://issues.apache.org/jira/browse/XERCESC-2006
> Project: Xerces-C++
>  Issue Type: Bug
> Environment: mingw
> icu 5 from trunk
> xerces-c from trunk
> gcc 4.7.2
>Reporter: Aleksey Dobrunov
>Assignee: Alberto Massari
> Fix For: 3.2.0
>
> Attachments: xerces_icu_prefix.m4.diff
>
>
> i am trying build xerces-c with icu
> reconf
> ./configure --enable-transcoder-icu  --enable-msgloader-icu --disable-network 
> in the end 
> configure:21971: Report:
> configure:21973:   File Manager: Windows
> configure:21975:   Mutex Manager: Windows
> configure:21977:   Transcoder: windows
> configure:21979:   NetAccessor: disabled
> configure:21981:   Message Loader: inmemory
> in config.log 
> configure:18085: checking for ucnv_open in -licuuc
> configure:18103: g++ -o conftest.exe -O2  -mthreads -I/icu1/include
> -lpthread -lm   -L/icu1/lib -licui18n -licuuc -licudata  -lpthread -lm 
> conftest.cpp  >&5
> C:\Users\ALEKSE~1.DOB\AppData\Local\Temp\ccg1wi5K.o:conftest.cpp:(.text.startup+0x1e):
>  undefined reference to `ucnv_open_51'
> collect2.exe: error: ld returned 1 exit status
> This error occurs because conftest.cpp specified later runtime libraries on 
> which it depends.
> this command work fine
> g++ -o conftest.exe -O2  conftest.cpp -mthreads -I/icu1/include-lpthread 
> -lm   -L/icu1/lib -licui18n -licuuc -licudata  -lpthread -lm  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Closed] (XERCESC-2009) crosscompilation fails in revision 1458655

[Alberto Massari (JIRA)]

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

Alberto Massari closed XERCESC-2009.


Resolution: Won't Fix
  Assignee: Alberto Massari

It is required to run the test program, as the function must be present AND 
behave as expected (i.e. set the input pointer to NULL if the conversion 
reached the end of the buffer)

> crosscompilation fails in revision 1458655
> --
>
> Key: XERCESC-2009
> URL: https://issues.apache.org/jira/browse/XERCESC-2009
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 3.1.0, 3.1.1
> Environment: Cross compiling for android on linux
>Reporter: Michael
>Assignee: Alberto Massari
>Priority: Trivial
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> Cross compiling Xerces-c fails since the current configure.ac relies on 
> AC_RUN_IFELSE when it checks for wcsrtombs and mbsrtowcs.
> The fix is:
> mkm@mkm:~/sandbox/build/android_external/xerces-c-trunk$ svn diff 
> configure.ac 
> Index: configure.ac
> ===
> --- configure.ac(revision 1458655)
> +++ configure.ac(working copy)
> @@ -161,7 +161,7 @@
>  ]
>   )
>  AC_MSG_CHECKING([for wcsrtombs])
> -AC_RUN_IFELSE(  [AC_LANG_PROGRAM([[#include 
> +AC_COMPILE_IFELSE(  [AC_LANG_PROGRAM([[#include 
>  #include ]],
>   [[
>  mbstate_t st;
> @@ -183,7 +183,7 @@
>  ]
>   )
>  AC_MSG_CHECKING([for mbsrtowcs])
> -AC_RUN_IFELSE(  [AC_LANG_PROGRAM([[#include 
> +AC_COMPILE_IFELSE(  [AC_LANG_PROGRAM([[#include 
>  #include ]],
>   [[
>  mbstate_t st;
> Best regards, Michael

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Closed] (XERCESC-2013) Xerces SAX parser gives segmentation fault, while parsing message

[Alberto Massari (JIRA)]

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

Alberto Massari closed XERCESC-2013.


Resolution: Cannot Reproduce
  Assignee: Alberto Massari

I couldn't reproduce it with Xerces 3.1 on Windows: I have modified the 
personal.xsd that ships with the Xerces samples to define the 'email' field as 
a simple type similar to your case (I just added the @ and the . character to 
the allowed characters)

  

  
  

  
  
 

Then I invoked 

saxprint -n -s -f -v=always samples\data\personal-schema.xml

and I didn't see any segmentation fault.

Can you try testing your schema with Xerces 3.1?


> Xerces SAX parser gives segmentation fault, while parsing message
> -
>
> Key: XERCESC-2013
> URL: https://issues.apache.org/jira/browse/XERCESC-2013
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: SAX/SAX2, Validating Parser (XML Schema)
>Affects Versions: 2.8.0
> Environment: Linux
>    Reporter: sunny
>Assignee: Alberto Massari
>  Labels: patch, performance
>
> I'm validating an xml message with an xsd which contains the following 
> element.
>   
> 
>   
>   
> 
>   
> I'm using sax parser for validation. For validating the data present in the 
> above element xerces parser gives segmentation fault. If i remove '*' from 
> pattern it is working fine.
> I replaced "" with  value="([a-zA-Z0-9_\-]){1,10}"/>, then it works fine but consumes lot of 
> memory and CPU.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Resolved] (XERCESC-2011) Xerces 3.1.1 Xerces.Lib fails to build with new Visual Studio 2012 Update 1 when v110_xp platform is chosen

[Alberto Massari (JIRA)]

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

Alberto Massari resolved XERCESC-2011.
--

   Resolution: Fixed
Fix Version/s: 3.2.0
 Assignee: Alberto Massari

A fix is in SVN. Please verify.

> Xerces 3.1.1 Xerces.Lib fails to build with new Visual Studio 2012 Update 1 
> when v110_xp platform is chosen
> ---
>
> Key: XERCESC-2011
> URL: https://issues.apache.org/jira/browse/XERCESC-2011
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 3.1.1
> Environment: VS2012 Update 1, platform set to V110_xp (introduced by 
> Update 1) instead of the pre-update V110.
> Windows 32-bit builds.
>    Reporter: DK
>Assignee: Alberto Massari
> Fix For: 3.2.0
>
>
> Same issue as defined in: 
> http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/ea289832-c48c-475b-a922-bf94d2ee54e4/
> Static Debug & Static Release compile without issue.  Normal Debug and 
> Release both have this issue. Not tested 64-bit builds.
> Compilation output has:
> 1>C:\Program Files (x86)\Microsoft Visual Studio 
> 11.0\VC\include\string.h(57): warning RC4011: identifier truncated to 
> '_CRT_SECURE_CPP_OVERLOAD_STANDA'
> 1>  
> 1>C:\Program Files (x86)\Microsoft Visual Studio 
> 11.0\VC\include\string.h(79): warning RC4011: identifier truncated to 
> '_CRT_SECURE_CPP_OVERLOAD_SECURE'
> 1>  
> 1>C:\Program Files (x86)\Microsoft Visual Studio 
> 11.0\VC\include\string.h(115): fatal error RC10056: 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: [VOTE]: Set up admin group for Xerces Wiki to eliminate SPAM

[Alberto Massari]

+1 also for me.

Alberto

Il 04/04/13 20:15, Michael Glavassevich ha scritto:

If you watch the commits list you'll have noticed that there's been an
increase in the amount SPAM getting posted to our Wiki. Other Apache
projects are suffering lately too.

Alberto and I have been cleaning it up, but I'm getting tired of seeing it
(almost) every day. :-)

The solution projects appear to be using to fight this is to set up an
AdminGroup [1]. This means only a trusted group can post to the Wiki,
rather than having it wide open like it's historically been. We can grant
access to people who ask for it, so this isn't going to block legitimate
folks from being able to post content.

I propose we ask INFRA to set up an AdminGroup with the following active
PMC members (Wiki user names):

Michael Glavassevich
BorisKolpackov
AlbertoMassari
Mukul Gandhi
GarethReakes

The infrastructure team would like to see that there's consensus with the
community before projects request this change, so I'm calling a vote.

To start here's my +1.

Thanks.

[1] http://s.apache.org/moin-wiki-access-control

Michael Glavassevich
XML Technologies and WAS Development
IBM Toronto Lab
E-mail: mrgla...@ca.ibm.com
E-mail: mrgla...@apache.org


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org





-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Closed] (XERCESC-1987) Transcoding Issue with single XMLCh to utf8

[Alberto Massari (JIRA)]

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

Alberto Massari closed XERCESC-1987.


Resolution: Won't Fix

The code in the trunk works correctly; we are not backporting fixes to 2.8 
though

> Transcoding Issue with single XMLCh to utf8
> ---
>
> Key: XERCESC-1987
> URL: https://issues.apache.org/jira/browse/XERCESC-1987
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 2.8.0
> Environment: Windows XP
>Reporter: Simon White
>
> There appears to be an issue with transcoding to utf8.  Conditions:
> Input string = Single Chinese Character (XmlCh holds value 27493).
> Problem code in TranscodeToStr::transcode:
> unsigned int allocSize = len * sizeof(XMLCh);
> fString = (XMLByte*)fMemoryManager->allocate(allocSize);
> This code sets the output buffer to be two bytes.  The issue here is that the 
> character in question converts to a 3 byte utf8 character.  It therefore hits 
> this in XMLUTF8Transcoder.cpp:
> //  If we cannot fully get this char into the output buffer,
> //  then leave it for the next time.
> //
> if (outPtr + encodedBytes > outEnd)
> break;
> Since this is only a single character being converted it returns 0 and then 
> hits this since nothing could be decoded:
> if(charsRead == 0)
> ThrowXMLwithMemMgr(TranscodingException, 
> XMLExcepts::Trans_BadSrcSeq, fMemoryManager);
> The sequence is not invalid, only output buffer has been limited to input 
> buffer size.  Is simply adding a few spare characters to allocSize the 
> correct fix?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Resolved] (XERCESC-1984) TranscodeToStr::transcode throws an exception when transcoding to UTF-8

[Alberto Massari (JIRA)]

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

Alberto Massari resolved XERCESC-1984.
--

   Resolution: Fixed
Fix Version/s: 3.2.0
 Assignee: Alberto Massari

A fix is in SVN. Please verify.

> TranscodeToStr::transcode throws an exception when transcoding to UTF-8
> ---
>
> Key: XERCESC-1984
> URL: https://issues.apache.org/jira/browse/XERCESC-1984
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 3.2.0, 4.0.0
> Environment: Bug reproducible on a Red Hat 5 based platform. The bug 
> doesn't seem to be platform specific though.
>    Reporter: Dan PV
>Assignee: Alberto Massari
>  Labels: exception, transcode
> Fix For: 3.2.0
>
> Attachments: transtest2.cpp
>
>
> This issue relates to the bug fix for issue XERCESC-1947. There are still 
> cases where the method will fail in providing a transcoded version without 
> throwing an exception. See the attached "transtest2.cpp" to reproduce the 
> issue.
> The cause seems to come from the added "if((allocSize - fBytesWritten) < (len 
> - charsDone))" condition in "TranscodeToStr::transcode" . In my provided test 
> case I have a string composed of 6 Japanese characters (i.e. "絞り込み検索"). Once 
> the first call to "XMLUTF8Transcoder::transcodeTo" is done, "charsRead" will 
> return a count of 5 XMLCh readed. Since the initial allocated buffer for this 
> string was set to 16 bytes, the condition will check against the following 
> values "if((16 - 15) < (6 - 5))" which avoids the reallocation of a larger 
> buffer for the UTF-8 encoded version of the string. 
> Since the reallocation doesn't take place, the code will recall 
> "XMLUTF8Transcoder::transcodeTo" but this time the "charsRead" count will be 
> set to 0 because there is insufficient space in the buffer and this will 
> trigger an exception of type "Trans_BadSrcSeq".
> I suppose that the goal of this added condition was to avoid an unnecessary 
> reallocation of a buffer but unfortunately it doesn’t work when transcoding 
> to variable length encoding like UTF-8. The solution is probably to simply 
> replace the condition with "if(charsDone < len)".
> Regards,
> Dan

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Updated] (XERCESC-2000) enumeration value ‘Loop’ not handled in switch src/SEnumVal/SEnumVal.cpp:

[Alberto Massari (JIRA)]

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

Alberto Massari updated XERCESC-2000:
-

Fix Version/s: (was: 3.1.2)
   3.2.0

> enumeration value ‘Loop’ not handled in switch src/SEnumVal/SEnumVal.cpp:
> -
>
> Key: XERCESC-2000
> URL: https://issues.apache.org/jira/browse/XERCESC-2000
> Project: Xerces-C++
>  Issue Type: Bug
>Reporter: james michael dupont
>        Assignee: Alberto Massari
>Priority: Trivial
> Fix For: 3.2.0
>
>
> src/SEnumVal/SEnumVal.cpp: In function ‘void processContentSpecNode(const 
> xercesc_3_1::ContentSpecNode*, bool)’:
> src/SEnumVal/SEnumVal.cpp:494:11: warning: enumeration value ‘Loop’ not 
> handled in switch

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Updated] (XERCESC-2001) no return statement in function returning non-void xercesc_3_1::formatNodeHolder& xercesc_3_1::formatNodeHolder::operator=(const xercesc_3_1::formatNodeHolder*)

[Alberto Massari (JIRA)]

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

Alberto Massari updated XERCESC-2001:
-

Fix Version/s: (was: 3.1.2)
   3.2.0

> no return statement in function returning non-void  
> xercesc_3_1::formatNodeHolder& xercesc_3_1::formatNodeHolder::operator=(const 
> xercesc_3_1::formatNodeHolder*)
> -
>
> Key: XERCESC-2001
> URL: https://issues.apache.org/jira/browse/XERCESC-2001
> Project: Xerces-C++
>  Issue Type: Bug
>Reporter: james michael dupont
>Assignee: Alberto Massari
> Fix For: 3.2.0
>
>
> xercesc/validators/common/ContentSpecNode.cpp: In member function 
> ‘xercesc_3_1::formatNodeHolder& 
> xercesc_3_1::formatNodeHolder::operator=(const 
> xercesc_3_1::formatNodeHolder*)’:
> xercesc/validators/common/ContentSpecNode.cpp:108:2: warning: no return 
> statement in function returning non-void

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Updated] (XERCESC-1997) VS2012 Project

[Alberto Massari (JIRA)]

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

Alberto Massari updated XERCESC-1997:
-

Fix Version/s: (was: 3.1.2)
   3.2.0

> VS2012 Project
> --
>
> Key: XERCESC-1997
> URL: https://issues.apache.org/jira/browse/XERCESC-1997
> Project: Xerces-C++
>  Issue Type: Improvement
>  Components: Build
>Affects Versions: 3.1.1
>Reporter: Pedro Larroy
>Assignee: Alberto Massari
> Fix For: 3.2.0
>
> Attachments: xerces_vc11proj.zip
>
>
> Hi 
> I attach project files for Visual studio 2012 for xerces-3.1.1

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Closed] (XERCESC-1989) Xerces 3.1.1 Xerces.Lib fails to build with new Visual Studio 2012 RC

[Alberto Massari (JIRA)]

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

Alberto Massari closed XERCESC-1989.


Resolution: Cannot Reproduce

I was able to compile the sources with the final version of Visual Studio 2012

> Xerces 3.1.1 Xerces.Lib fails to build with new Visual Studio 2012 RC
> -
>
> Key: XERCESC-1989
> URL: https://issues.apache.org/jira/browse/XERCESC-1989
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 3.1.1
> Environment: Windows 7, new Visual Studio 2012 RC. Building x86 
> XercesLib.
>Reporter: DK
>Priority: Minor
>   Original Estimate: 5m
>  Remaining Estimate: 5m
>
> Error during resource compile. I raised it as an issue with MS Connect and 
> the response states that it is due to a change in "winnt.h" where previous 
> warning messages are now error messages.
> Text from MS reply is:
> The reason this is a build error now, instead of a build warning, is due to a 
> change in winnt.h.  If you look at line 141, you'll reach the #error 
> statement on this line because none of the architecture constants are defined.
> There are a couple of ways to work around this build error, in order of 
> preference:
> 1.  Remove the #include  statement from your .rc files if it's not 
> needed.
> 2.  Replace the #include  statement with #include  or 
> #include 
> 3.  If you really need to keep the #include  statement in place, you 
> can define one of the architecture constants before the #include line, for 
> example:
> #define _X86_
> #include 
> I have tested '2' by changing 'winnt.h' to 'winnt.rh' on lines 11 & 87 in 
> xerces-c-3.1.1\src\xercesc\util\MsgLoaders\Win32\Version.rc and it now 
> compiles and links without error.
> Obviously, your choice of option suggested by MS that you wish to employ.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Updated] (XERCESC-1997) VS2012 Project

[Alberto Massari (JIRA)]

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

Alberto Massari updated XERCESC-1997:
-

Fix Version/s: 3.1.2

> VS2012 Project
> --
>
> Key: XERCESC-1997
> URL: https://issues.apache.org/jira/browse/XERCESC-1997
> Project: Xerces-C++
>  Issue Type: Improvement
>  Components: Build
>Affects Versions: 3.1.1
>Reporter: Pedro Larroy
>Assignee: Alberto Massari
> Fix For: 3.1.2
>
> Attachments: xerces_vc11proj.zip
>
>
> Hi 
> I attach project files for Visual studio 2012 for xerces-3.1.1

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Resolved] (XERCESC-2000) enumeration value ‘Loop’ not handled in switch src/SEnumVal/SEnumVal.cpp:

[Alberto Massari (JIRA)]

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

Alberto Massari resolved XERCESC-2000.
--

   Resolution: Fixed
Fix Version/s: 3.1.2
 Assignee: Alberto Massari

A fix is in SVN. Please verify. Alberto

> enumeration value ‘Loop’ not handled in switch src/SEnumVal/SEnumVal.cpp:
> -
>
> Key: XERCESC-2000
> URL: https://issues.apache.org/jira/browse/XERCESC-2000
> Project: Xerces-C++
>  Issue Type: Bug
>Reporter: james michael dupont
>        Assignee: Alberto Massari
>Priority: Trivial
> Fix For: 3.1.2
>
>
> src/SEnumVal/SEnumVal.cpp: In function ‘void processContentSpecNode(const 
> xercesc_3_1::ContentSpecNode*, bool)’:
> src/SEnumVal/SEnumVal.cpp:494:11: warning: enumeration value ‘Loop’ not 
> handled in switch

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Resolved] (XERCESC-2001) no return statement in function returning non-void xercesc_3_1::formatNodeHolder& xercesc_3_1::formatNodeHolder::operator=(const xercesc_3_1::formatNodeHolder*)

[Alberto Massari (JIRA)]

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

Alberto Massari resolved XERCESC-2001.
--

   Resolution: Fixed
Fix Version/s: 3.1.2
 Assignee: Alberto Massari

A fix is in SVN. Please verify. Alberto

> no return statement in function returning non-void  
> xercesc_3_1::formatNodeHolder& xercesc_3_1::formatNodeHolder::operator=(const 
> xercesc_3_1::formatNodeHolder*)
> -
>
> Key: XERCESC-2001
> URL: https://issues.apache.org/jira/browse/XERCESC-2001
> Project: Xerces-C++
>  Issue Type: Bug
>Reporter: james michael dupont
>Assignee: Alberto Massari
> Fix For: 3.1.2
>
>
> xercesc/validators/common/ContentSpecNode.cpp: In member function 
> ‘xercesc_3_1::formatNodeHolder& 
> xercesc_3_1::formatNodeHolder::operator=(const 
> xercesc_3_1::formatNodeHolder*)’:
> xercesc/validators/common/ContentSpecNode.cpp:108:2: warning: no return 
> statement in function returning non-void

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Closed] (XERCESC-2008) xsi:type whiteSpace facet

[Alberto Massari (JIRA)]

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

Alberto Massari closed XERCESC-2008.


Resolution: Duplicate

Duplicate of XERCESC-1945

> xsi:type whiteSpace facet
> -
>
> Key: XERCESC-2008
> URL: https://issues.apache.org/jira/browse/XERCESC-2008
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Validating Parser (XML Schema)
>Affects Versions: 2.8.0, 3.0.0, 3.1.0, 3.1.1
> Environment: Windows 7, Command Prompt, example program DOMCount. 
>Reporter: Herbert Oppmann
>Priority: Minor
>
> With the example below, the validation returns "type ' ItemT' specified in 
> 'xsi:type' cannot be resolved".
> Obviously, Xerces does not do Attribute Value Normalization applying 
> whiteSpace="collapse" on the attribute 'xsi:type'.
> The value of the attribute 'xsi:type' is QName (see 
> http://www.w3.org/TR/xmlschema-1/#xsi_type). QName is an atomic type (see 
> http://www.w3.org/TR/xmlschema-2/#built-in-datatypes). For atomic datatypes 
> the value of the whiteSpace facet is 'collapse' (see 
> http://www.w3.org/TR/xmlschema-2/#rf-whiteSpace).
> The command line used is: DOMCount.exe -v=always -s -f -n Type.xml
> Schema Type.xsd:
> 
> http://www.w3.org/2001/XMLSchema"; 
> xmlns:test="http://www.example.com/Type"; 
> targetNamespace="http://www.example.com/Type"; elementFormDefault="qualified" 
> attributeFormDefault="unqualified">
>   
>   
>   
>maxOccurs="unbounded"/>
>   
>   
>   
>   
>   
>   
> 
> Example Type.xml:
> 
> http://www.w3.org/2001/XMLSchema-instance"; 
> xmlns="http://www.example.com/Type"; 
> xsi:schemaLocation="http://www.example.com/Type Type.xsd">
>   
>   
> 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Resolved] (XERCESC-1997) VS2012 Project

[Alberto Massari (JIRA)]

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

Alberto Massari resolved XERCESC-1997.
--

Resolution: Fixed
  Assignee: Alberto Massari

I finally got VS2012 installed and could perform the upgrade myself. Thanks

> VS2012 Project
> --
>
> Key: XERCESC-1997
> URL: https://issues.apache.org/jira/browse/XERCESC-1997
> Project: Xerces-C++
>  Issue Type: Improvement
>  Components: Build
>Affects Versions: 3.1.1
>Reporter: Pedro Larroy
>Assignee: Alberto Massari
> Attachments: xerces_vc11proj.zip
>
>
> Hi 
> I attach project files for Visual studio 2012 for xerces-3.1.1

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Commented] (XERCESC-1975) InvalidDatatypeValueException thrown when parsing a UnionDataType

[Alberto Massari (JIRA)]

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

Alberto Massari commented on XERCESC-1975:
--

Yes, the exception is expected, and handled: the 
UnionDatatypeValidator::checkContent attempts to validate the incoming data 
with every child validator, and stops when one of them accepts it. If all of 
them throw a validation error, then a different exception 
(VALUE_no_match_memberType) is thrown.


> InvalidDatatypeValueException thrown when parsing a UnionDataType
> -
>
> Key: XERCESC-1975
> URL: https://issues.apache.org/jira/browse/XERCESC-1975
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Validating Parser (XML Schema)
>Affects Versions: 3.1.1
>Reporter: Ashish Singhal
>Priority: Blocker
> Attachments: TestDoc.xml, TestSchema.xsd
>
>
> InvalidDatatypeValueException is thrown when parsing an XML document that 
> contains a Union data type and the union is contains another simple data 
> type, eg:
> Given this schema:
> http://www.w3.org/2001/XMLSchema"; 
> elementFormDefault="qualified" attributeFormDefault="unqualified">
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
> 
> This XML should be valid:
> 
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> testAttribute="true"
> >
> 
> 
> However an InvalidDatatypeValueException is thrown when validating this 
> document.
> Changing my schema to remove SubPattern from the SubString union, fixes the 
> issue, but it's not the solution I'm looking for. 
> I would like xerces-c to validate the document correctly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Resolved] (XERCESC-2004) bit operation error in DOMNodeImpl::reverseTreeOrderBitPattern

[Alberto Massari (JIRA)]

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

Alberto Massari resolved XERCESC-2004.
--

   Resolution: Fixed
Fix Version/s: 3.2.0
 Assignee: Alberto Massari

Thanks for spotting this; the fix is now in SVN

> bit operation error in DOMNodeImpl::reverseTreeOrderBitPattern 
> ---
>
> Key: XERCESC-2004
> URL: https://issues.apache.org/jira/browse/XERCESC-2004
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: DOM
>Affects Versions: 3.1.1
> Environment: any
>Reporter: 朱亚东
>    Assignee: Alberto Massari
> Fix For: 3.2.0
>
>
> code like below:
> short DOMNodeImpl::reverseTreeOrderBitPattern(short pattern) const {
> if(pattern & DOMNode::DOCUMENT_POSITION_PRECEDING) {
> pattern &= !DOMNode::DOCUMENT_POSITION_PRECEDING;
> pattern |= DOMNode::DOCUMENT_POSITION_FOLLOWING;
> }
> I think it should be:
> short DOMNodeImpl::reverseTreeOrderBitPattern(short pattern) const {
> if(pattern & DOMNode::DOCUMENT_POSITION_PRECEDING) {
> pattern &= ~DOMNode::DOCUMENT_POSITION_PRECEDING;
> pattern |= DOMNode::DOCUMENT_POSITION_FOLLOWING;
> }
> because !DOMNode::DOCUMENT_POSITION_PRECEDING always be 0.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Closed] (XERCESC-2005) Cannot possible to append imported node

[Alberto Massari (JIRA)]

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

Alberto Massari closed XERCESC-2005.


Resolution: Invalid

Please don't open bugs to ask questions: use c-us...@xerces.apache.org instead

> Cannot possible to append imported node
> ---
>
> Key: XERCESC-2005
> URL: https://issues.apache.org/jira/browse/XERCESC-2005
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: DOM
>Affects Versions: 3.1.1
> Environment: Windows XP
>Reporter: subins jose
>  Labels: Exception, appendchild, importNode
> Fix For: 3.1.1
>
>
> I have one node, that is imported from second document. When I try to append 
> this node to first node, it throws an exception.
> DOMImplementation* pDOMImplementation = 
> DOMImplementationRegistry::getDOMImplementation(XMLString::transcode( "CORE" 
> ));
>   pDOMParser = 
> pDOMImplementation->createLSParser(DOMImplementationLS::MODE_SYNCHRONOUS, 0);
>   if( pDOMParser->getDomConfig()->canSetParameter( XMLUni::fgDOMValidate, 
> true ) )
>   pDOMParser->getDomConfig()->setParameter( 
> XMLUni::fgDOMValidate, true );
>   if( pDOMParser->getDomConfig()->canSetParameter( 
> XMLUni::fgDOMNamespaces, true ) )
>   pDOMParser->getDomConfig()->setParameter( 
> XMLUni::fgDOMNamespaces, true );
>   if( pDOMParser->getDomConfig()->canSetParameter( 
> XMLUni::fgDOMDatatypeNormalization, true ) )
>   pDOMParser->getDomConfig()->setParameter( 
> XMLUni::fgDOMDatatypeNormalization, true );
>   pFirstDOMDocumnt = pDOMParser->parseURI(path);
>   pSecondDOMDocumnt = pDOMParser->parseURI(path);
>   
>   ..
> try
> {
>   DOMNode* pImportedNode =pSecondDOMDocumnt->importNode(pChild, true);
>   pParent->appendChild(pChildElement);
> }
> catch(DOMException exe)
> {
>   fprintf(stdout,"Exception : %S\n",exe.getMessage());
> }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Performance of DOMNodeList in form loops

[Alberto Massari]

Hi Kelly,
given your requirements, have you tried using the 
createNodeIterator/createTreeWalker APIs exposed by DOMDocument?


Alberto

Il 25/10/2012 16:12, Kelly Davis ha scritto:

In our code we have many loops of the form

XMLCh *namespace = ...
XMLCh *elementName = ...
DOMNodeList *domNodeList =  domElement->getElementsByTagNameNS(namespace, 
elementName);
XMLSize_t domNodeListSize = domNodeList->getLength();
for (XMLSize_t count = 0; count < domNodeListSize; ++count) {
 DOMElement *nextDOMElement = (DOMElement *) domNodeList->item(count);
 // Modify nextDOMElement by adding attributes
}

These are extremely slow.

The problem seems to be multi-fold:

1. The API has no getElementsByTagNameNS() that returns a "const DOMNodeList*", 
thus allowing optimizations. (Not xerces-c's fault, but it's a nice-to-have!)
2. DOMNodeList:: getLength() is order O(V + E), where V is the number of 
DOMElements under domElement and E is the number of edges
3. DOMNodeList:: item(XMLSize_t index) is of oder O(V + E) as nextDOMElement's 
attributes are modified and thus the DOMDocument's fChanges is incremented

These yield a for loop that is of O((V + E)^2), which for the number of such 
loops we have is far, far to slow.

Short of re-writing DOMDeepNodeListImpl, what is the proper solution to this 
problem?

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

.




-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Commented] (XERCESC-2002) XMLString::transcode for multi-byte characters are returning null on Linux

[Alberto Massari (JIRA)]

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

Alberto Massari commented on XERCESC-2002:
--

I am still waiting for an answer to the "If that fails, check which transcoder 
has been selected when building Xerces, because that changes what is considered 
the default locale" part of the comment

> XMLString::transcode for multi-byte characters are returning null on Linux 
> ---
>
> Key: XERCESC-2002
> URL: https://issues.apache.org/jira/browse/XERCESC-2002
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Miscellaneous
>Affects Versions: 2.7.0
>Reporter: Ratnesh Nath
>Priority: Critical
>
> XMLCh *tag1 = XMLString::transcode("test-in-english");
> Printing: CsEws::XmlChToString(tag1).c_str()); >>>>>>> output is : 
> test-in-english
> XMLCh *tag2 = XMLString::transcode("ã«ã¯");
> Printing: CsEws::XmlChToString(tag1).c_str()); >>>>>>> output is :  <<< NULL

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Commented] (XERCESC-2002) XMLString::transcode for multi-byte characters are returning null on Linux

[Alberto Massari (JIRA)]

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

Alberto Massari commented on XERCESC-2002:
--

No, I am saying not to use non-ASCII characters in a C++ source file, as you 
never know how they are read by the compiler; in your case, it should be 
something like \xC3\xA3\xC2\xAB\xC3\xA3\xC2\xAF (assuming you want to transcode 
the string ã«ã¯ )

> XMLString::transcode for multi-byte characters are returning null on Linux 
> ---
>
> Key: XERCESC-2002
> URL: https://issues.apache.org/jira/browse/XERCESC-2002
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Miscellaneous
>Affects Versions: 2.7.0
>Reporter: Ratnesh Nath
>Priority: Critical
>
> XMLCh *tag1 = XMLString::transcode("test-in-english");
> Printing: CsEws::XmlChToString(tag1).c_str()); >>>>>>> output is : 
> test-in-english
> XMLCh *tag2 = XMLString::transcode("ã«ã¯");
> Printing: CsEws::XmlChToString(tag1).c_str()); >>>>>>> output is :  <<< NULL

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Commented] (XERCESC-2002) XMLString::transcode for multi-byte characters are returning null on Linux

[Alberto Massari (JIRA)]

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

Alberto Massari commented on XERCESC-2002:
--

Try with a) writing the string to transcode using escape characters ("\x80") 
and b) printing the single XMLCh character instead of going through 
CsEws::XmlChToString so that we can rule out other possibilities. If that 
fails, check which transcoder has been selected when building Xerces, because 
that changes what is considered the default locale

> XMLString::transcode for multi-byte characters are returning null on Linux 
> ---
>
> Key: XERCESC-2002
> URL: https://issues.apache.org/jira/browse/XERCESC-2002
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Miscellaneous
>Affects Versions: 2.7.0
>Reporter: Ratnesh Nath
>Priority: Critical
>
> XMLCh *tag1 = XMLString::transcode("test-in-english");
> Printing: CsEws::XmlChToString(tag1).c_str()); >>>>>>> output is : 
> test-in-english
> XMLCh *tag2 = XMLString::transcode("ã«ã¯");
> Printing: CsEws::XmlChToString(tag1).c_str()); >>>>>>> output is :  <<< NULL

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Closed] (XERCESC-2002) XMLString::transcode for multi-byte characters are returning null on Linux

[Alberto Massari (JIRA)]

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

Alberto Massari closed XERCESC-2002.


Resolution: Invalid

XMLString::transcode converts to/from the current locale. It's up to the user 
to guarantee that the char* specified as argument is a valid string for the 
current locale. I guess your locale is not UTF-8, and so the conversion fails. 
You should create a transcoder for the encoding of the input string, and use 
XMLString::transcode only for data coming from stdin, or being printed to stdout

> XMLString::transcode for multi-byte characters are returning null on Linux 
> ---
>
> Key: XERCESC-2002
> URL: https://issues.apache.org/jira/browse/XERCESC-2002
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Miscellaneous
>Affects Versions: 2.7.0
>Reporter: Ratnesh Nath
>Priority: Critical
>
> XMLCh *tag1 = XMLString::transcode("test-in-english");
> Printing: CsEws::XmlChToString(tag1).c_str()); >>>>>>> output is : 
> test-in-english
> XMLCh *tag2 = XMLString::transcode("ã«ã¯");
> Printing: CsEws::XmlChToString(tag1).c_str()); >>>>>>> output is :  <<< NULL

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: consistent error messages (and more)

[Alberto Massari]

Thanks for reporting this, it is fixed in SVN now.

Alberto

Il 08/10/2012 17:19, Denis Excoffier ha scritto:

Hi,

If you want consistent error messages, not like
"invalid character 0x1e" and
"invalid character 0x1F", you will want to apply the patch included
(either Xerces-C-3.1.1 or trunk)

Regards,

Denis Excoffier.



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: xerces trunk on openbsd 5.1

[Alberto Massari]

Hi Simon,
it looks that libc in OpenBSD 5.1 is not obeying to the documentation 
for wcsrtombs/mbsrtowcs.


If_d__s__t_  is not a null pointer, the pointer object pointed  to
by_s__r__c_   is  assigned  either  a null pointer (if conversion
stopped due to reaching a terminating  null  wide-character)
or  the address just  past the last wide-character converted
(if any).

Instead of hacking the code to try to detect whether the conversion 
actually wrote a NULL character in the converted string, I chose to 
modify the 'configure' script to detect this behaviour and disable the 
usage of the re-entrant functions if it doesn't match how the Xerces 
code uses them.


Thank you for reporting this issue,
Alberto

Il 28/09/2012 00:18, Simon Elbaz ha scritto:

Hi,

I wanted to try using xerces on openbsd 5.1.

After compilation, DOMCount was always returning:
unknow reason.

After reading the code, it turns out that the end of conversion by 
wcsrtombs and mbsrtowcs is based on a test on source pointer (source 
pointer should point on null character).


The problem is that this behaviour is not implemented. Source pointer 
points on the character following the last converted character leading 
xerces binary to a risky memory access.


Below, there is a patch based on values returned by the functions (-1 
in case of error, >= 0 in case of complete/incomplete conversion) that 
fixes the problem.


Regards,
Simon Elbaz

$ svn diff xercesc/util/Transcoders/Iconv/IconvTransService.cpp
Index: xercesc/util/Transcoders/Iconv/IconvTransService.cpp
===
--- xercesc/util/Transcoders/Iconv/IconvTransService.cpp (revision 
1387785)

+++ xercesc/util/Transcoders/Iconv/IconvTransService.cpp (working copy)
@@ -429,7 +429,7 @@
 srcBuffer[gTempBuffArraySize - 1] = 0;
 const wchar_t *src = 0;

-while (toTranscode[srcCursor] || src)
+while (toTranscode[srcCursor])
 {
 if (src == 0) // copy a piece of the source string into a local
   // buffer, converted to wchar_t and 
NULL-terminated.

@@ -454,7 +454,7 @@
 break;
 }
 dstCursor += len;
-if (src != 0) // conversion not finished. This *always* means 
there
+if (len == (resultSize - dstCursor)) // conversion not 
finished. This *always* means there

   // was not enough room in the destination buffer.
 {
 reallocString(resultString, resultSize, manager, 
resultString != localBuffer);

@@ -512,9 +512,9 @@
 break;
 }
 dstCursor += len;
-if (src == 0) // conversion finished
+if ((len >= 0) && (len < (resultSize - dstCursor))) // 
conversion finished

 break;
-if (dstCursor >= resultSize - 1)
+if (len == (resultSize - dstCursor))
 reallocString(tmpString, resultSize, manager, 
tmpString != localBuffer);

 }
 // make a final copy, converting from wchar_t to XMLCh:

[jira] [Commented] (XERCESC-1996) Chinese characters are not parsed correctly

[Alberto Massari (JIRA)]

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

Alberto Massari commented on XERCESC-1996:
--

Could you specify which string isn't represented correctly, and what should be 
the correct label?

Thanks

> Chinese characters are not parsed correctly
> ---
>
> Key: XERCESC-1996
> URL: https://issues.apache.org/jira/browse/XERCESC-1996
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: DOM
>Affects Versions: 3.1.1
> Environment: Windows 2008 R2 64 bit
>Reporter: Shreedhara Udupa 
> Attachments: ChineseXML.xml
>
>
> When xml file (Refer attached) with chinese characters are parsed few 
> character are missed.  In the attached xml group names are not parsed .  Few 
> character are missed

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Commented] (XERCESC-1995) Allow compiling Xerces-C using C++11 (especially Clang)

[Alberto Massari (JIRA)]

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

Alberto Massari commented on XERCESC-1995:
--

Yes, we try to avoid newer keywords unless they are really needed, to avoid 
dropping old compilers for unnecessary reasons

> Allow compiling Xerces-C using C++11 (especially Clang)
> ---
>
> Key: XERCESC-1995
> URL: https://issues.apache.org/jira/browse/XERCESC-1995
> Project: Xerces-C++
>  Issue Type: Improvement
>  Components: Utilities
>Affects Versions: 3.1.1
> Environment: Shouldn't matter (FreeBSD9.1 RC1)
>Reporter: Michael Gmelin
>Assignee: Alberto Massari
>Priority: Minor
>  Labels: patch
> Fix For: 3.2.0
>
> Attachments: CompileXercersC++11.patch
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> gcc issues a couple of warnings in C++11 about narrowing conversions, clang 
> refuses to build for the same reason.
> The attached patch solves this trivial problem by adding a few static casts 
> in the right places.
> While you're on it you might also want to apply XERCESC-1994, which had been 
> revealed by compiling xerces-c using Clang.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Resolved] (XERCESC-1994) ContentSpecNode::getMaxTotalRange: Operator precedence flaw

[Alberto Massari (JIRA)]

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

Alberto Massari resolved XERCESC-1994.
--

   Resolution: Fixed
Fix Version/s: 3.2.0
 Assignee: Alberto Massari

A fix is in SVN. Please verify.

> ContentSpecNode::getMaxTotalRange: Operator precedence flaw
> ---
>
> Key: XERCESC-1994
> URL: https://issues.apache.org/jira/browse/XERCESC-1994
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Validating Parser (XML Schema)
>Affects Versions: 3.1.1
> Environment: Not relevant, C++ syntax problem
>Reporter: Michael Gmelin
>    Assignee: Alberto Massari
> Fix For: 3.2.0
>
> Attachments: ContentSpecNode.cpp.patch
>
>   Original Estimate: 0.25h
>  Remaining Estimate: 0.25h
>
> ContentSpecType.cpp says at about line 260:
> if ((fType & 0x0f) == ContentSpecNode::Choice) {
> max = max * (maxFirst > maxSecond) ? maxFirst : maxSecond;
> }
> Thanks to operator precedence max evaluates either to maxFirst or maxSecond, 
> but never to max*maxFirst or max*maxSecond.
> Adding parenthesis makes this do the right thing:
> max = max * ((maxFirst > maxSecond) ? maxFirst : 
> maxSecond);

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Resolved] (XERCESC-1995) Allow compiling Xerces-C using C++11 (especially Clang)

[Alberto Massari (JIRA)]

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

Alberto Massari resolved XERCESC-1995.
--

   Resolution: Fixed
Fix Version/s: 3.2.0
 Assignee: Alberto Massari

A fix is in SVN. Please verify.

> Allow compiling Xerces-C using C++11 (especially Clang)
> ---
>
> Key: XERCESC-1995
> URL: https://issues.apache.org/jira/browse/XERCESC-1995
> Project: Xerces-C++
>  Issue Type: Improvement
>  Components: Utilities
>Affects Versions: 3.1.1
> Environment: Shouldn't matter (FreeBSD9.1 RC1)
>Reporter: Michael Gmelin
>Assignee: Alberto Massari
>Priority: Minor
>  Labels: patch
> Fix For: 3.2.0
>
> Attachments: CompileXercersC++11.patch
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> gcc issues a couple of warnings in C++11 about narrowing conversions, clang 
> refuses to build for the same reason.
> The attached patch solves this trivial problem by adding a few static casts 
> in the right places.
> While you're on it you might also want to apply XERCESC-1994, which had been 
> revealed by compiling xerces-c using Clang.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: Fwd: Why does Xerces modify an invalid XML file while parsing?

[Alberto Massari]

Il 17/07/2012 08:21, neetha patil ha scritto:

Dear All,
Thank you Alberto for guiding me to get rid of the "Unknown element" 
validation errors.
I tried setting the parameter 'XMLUni::fgDOMErrorHandler' for the 
DOMBuilderparser but there it had no such parameter and also I am 
using the DOM document which is returned after parsing.


I forgot that in the new DOM L3 the parameters are set through an 
intermediate object. The correct call should be something like 
(*pParser)->getDOMConfiguration()->setParameter. (Double check it, I 
could remember the name wrong, but that should give you the idea)


DOMBuilderparser (while parsing against the schema) reports  the 
first schema-related error and continues with further parsing and 
reporting of other schema-related errors (if any). Is it possible for 
the DOMBuilderparser to behave in the same way (and not do any 
auto-modification) when there are invalid XML statement(s) like the 
one reported in my previous mail?


No; validation errors are not fatal while invalid XML syntax could be 
non-recoverable. In your case the parser tries to find a new 
synchronization point at the first ">" it finds, but if you missed the 
closing quote at the end of an attribute you would be in much bigger 
troubles.


What I am trying to make you understand is that an invalid XML cannot 
generate a DOM representation that reflects the input XML, because by 
serializing a DOM representation you will get a *valid* XML, not the 
original invalid one. The correct thing to do is reject the input XML 
you got; if you want to still be able to read and manipulate it, what 
you call "auto-modification" is the only thing you can do.


Alberto



Regards,
Neetha

On Mon, Jul 16, 2012 at 5:03 PM, Alberto Massari 
mailto:alberto.mass...@progress.com>> 
wrote:


Hi Neetha,
the correct thing to do would be to not make these calls


(*pParser)->setFeature( XMLUni::fgXercesSchema, true );
  (*pParser)->setFeature(
XMLUni::fgXercesSchemaFullChecking, true );
  (*pParser)->setFeature( XMLUni::fgDOMValidation, true);
  (*pParser)->setFeature(
XMLUni::fgXercesCacheGrammarFromParse, true);

when bValidate == false, as you are asking to validate against a
schema that you are not going to provide. This will remove the
"Unknown element" validation errors. As for what you say it's an
"auto-modification", it's the correct behaviour:  is
not a valid XML statement (either there is a missing tag name, and
"name" is an attribute, or "name" is the element and it's missing
a space followed by the attribute name. If you force the parser to
continue, the DOM tree you get back will be incomplete, at best.
If you really want to get a DOM tree out of that invalid XML, you
could attach a W3C DOMErrorHandler (different from the one you
provided) using
(*pParser)->setParameter(XMLUni::fgDOMErrorHandler,
domErrorHandlerVar)
This class has a handleError method where you can check what
happened by examining the DOMError argument, and the DOMLocation
inside it (it contains the DOM node where the error was located).
If you return "true", the parser will try continuing the parse
process; if you return "false", parsing will be aborted.

Alberto


Il 16/07/2012 12:06, neetha patil ha scritto:

Dear Alberto,
Thank you for the quick reply.
As I do not load the grammar (schema) to the parser, it gives
error like "Unknown element.." etc., for all the XML tags until
it hits the invalid tag for which it gives the error 'Expected an
attribute name' and aborts parsing as you mentioned.
So I set the feature 'XMLUni::fgXercesContinueAfterFatalError' to
true and got the complete file parsed. However the line
containing the invalid tag was modified as follows:-
...
...

 ...
 ...

...

...
...

...
...
As it is told in
http://xml.apache.org/xerces-c-new/program-dom.html that setting
this feature to true might result in an *undetermined* behavior
of the parser, is there any other way for the parser to report
the error and continue parsing? Also can we prevent the
auto-modification (in this case, the modification from
 to )?
Thanks
Regards,
Neetha

On Mon, Jul 16, 2012 at 2:39 PM, Alberto Massari
mailto:alberto.mass...@progress.com>> wrote:

Hi,
Xerces doesn't modify your document; you should check the
error handler to see if the parsing was aborted because of an
error. In this case the returned DOM tree would be complete
up to position of the error.

Alberto

Il 16/07/2012 10:25, neetha patil ha scritto

Re: Fwd: Why does Xerces modify an invalid XML file while parsing?

[Alberto Massari]

Hi Neetha,
the correct thing to do would be to not make these calls

 (*pParser)->setFeature( XMLUni::fgXercesSchema, true );
  (*pParser)->setFeature( 
XMLUni::fgXercesSchemaFullChecking, true );

  (*pParser)->setFeature( XMLUni::fgDOMValidation, true);
  (*pParser)->setFeature( 
XMLUni::fgXercesCacheGrammarFromParse, true);


when bValidate == false, as you are asking to validate against a schema 
that you are not going to provide. This will remove the "Unknown 
element" validation errors. As for what you say it's an 
"auto-modification", it's the correct behaviour:  is not a 
valid XML statement (either there is a missing tag name, and "name" is 
an attribute, or "name" is the element and it's missing a space followed 
by the attribute name. If you force the parser to continue, the DOM tree 
you get back will be incomplete, at best.
If you really want to get a DOM tree out of that invalid XML, you could 
attach a W3C DOMErrorHandler (different from the one you provided) using 
(*pParser)->setParameter(XMLUni::fgDOMErrorHandler, domErrorHandlerVar)
This class has a handleError method where you can check what happened by 
examining the DOMError argument, and the DOMLocation inside it (it 
contains the DOM node where the error was located). If you return 
"true", the parser will try continuing the parse process; if you return 
"false", parsing will be aborted.


Alberto


Il 16/07/2012 12:06, neetha patil ha scritto:

Dear Alberto,
Thank you for the quick reply.
As I do not load the grammar (schema) to the parser, it gives error 
like "Unknown element.." etc., for all the XML tags until it hits the 
invalid tag for which it gives the error 'Expected an attribute name' 
and aborts parsing as you mentioned.
So I set the feature 'XMLUni::fgXercesContinueAfterFatalError' to true 
and got the complete file parsed. However the line containing the 
invalid tag was modified as follows:-

...
...

 ...
 ...

...

...
...

...
...
As it is told in http://xml.apache.org/xerces-c-new/program-dom.html 
that setting this feature to true might result in an *undetermined* 
behavior of the parser, is there any other way for the parser to 
report the error and continue parsing? Also can we prevent the 
auto-modification (in this case, the modification from  to 
)?

Thanks
Regards,
Neetha

On Mon, Jul 16, 2012 at 2:39 PM, Alberto Massari 
mailto:alberto.mass...@progress.com>> 
wrote:


Hi,
Xerces doesn't modify your document; you should check the error
handler to see if the parsing was aborted because of an error. In
this case the returned DOM tree would be complete up to position
of the error.

Alberto

Il 16/07/2012 10:25, neetha patil ha scritto:

Dear All,

I am using Xercesc_2_8 C++. I provide a XML file (containing an
invalid tag) to the

DOMBuilderparser. I then edit the DOM document which is generated
and save the document back to the XML file. The content of this
file is now truncated from the invalid tag onwards. Why does the
parser modify the file while parsing? How do I prevent the same?
i.e., I want the parser to report the error and continue parsing
but not modify the XML content.
Following is the snapshot of the XML file:-
...
...

 ...

 ...
 ...

 ...
 ...



...
...
　
Following is the code snippet of the parser:-
*void CHelper::InitDOM()
*{
// m_pDomImpl is a pointer to DOMImplementation
m_pDomImpl = 0;
if(m_pDomImpl == NULL)
{
  XMLPlatformUtils::Initialize();
  m_pDomImpl =
DOMImplementationRegistry::getDOMImplementation( gLS );
 }
}
*int CHelper::LoadFile(DOMBuilder** pParser, const CString&
strXMLFile, DOMDocument** pDoc, CStringArray& arrError, bool
bValidate, const CString& strSchemaFile)
*{
   ...
   if(*pParser == NULL)
   {
  *pParser =
((DOMImplementationLS*)m_pDomImpl)->createDOMBuilder

 (DOMImplementationLS::MODE_SYNCHRONOUS,
 0 );
   if((*pParser) ==NULL)
  {
return DOM_INITIALIZE_FAILED;
  }

  (*pParser)->setFeature( XMLUni::fgDOMNamespaces,
true );
  (*pParser)->setFeature( XMLUni::fgXercesSchema, true );
  (*pParser)->setFeature(
XMLUni::fgXercesSchemaFullChecking, true );
  (*pParser)->setFeature( XMLUni::fgDOMValidation, true);
  (*pParser)->setFeature(
XMLUni::fgXerce

Re: Fwd: Why does Xerces modify an invalid XML file while parsing?

[Alberto Massari]

Hi,
Xerces doesn't modify your document; you should check the error handler 
to see if the parsing was aborted because of an error. In this case the 
returned DOM tree would be complete up to position of the error.


Alberto

Il 16/07/2012 10:25, neetha patil ha scritto:

Dear All,

I am using Xercesc_2_8 C++. I provide a XML file (containing an 
invalid tag) to the


DOMBuilderparser. I then edit the DOM document which is generated and 
save the document back to the XML file. The content of this file is 
now truncated from the invalid tag onwards. Why does the parser modify 
the file while parsing? How do I prevent the same? i.e., I want the 
parser to report the error and continue parsing but not modify the XML 
content.

Following is the snapshot of the XML file:-
...
...
version="1">

 ...

 ...
 ...

 ...
 ...



...
...
　
Following is the code snippet of the parser:-
*void CHelper::InitDOM()
*{
// m_pDomImpl is a pointer to DOMImplementation
m_pDomImpl = 0;
if(m_pDomImpl == NULL)
{
  XMLPlatformUtils::Initialize();
  m_pDomImpl = 
DOMImplementationRegistry::getDOMImplementation( gLS );

 }
}
*int CHelper::LoadFile(DOMBuilder** pParser, const CString& 
strXMLFile, DOMDocument** pDoc, CStringArray& arrError, bool 
bValidate, const CString& strSchemaFile)

*{
   ...
   if(*pParser == NULL)
   {
  *pParser = 
((DOMImplementationLS*)m_pDomImpl)->createDOMBuilder
 (DOMImplementationLS::MODE_SYNCHRONOUS, 
 0 );

   if((*pParser) ==NULL)
  {
return DOM_INITIALIZE_FAILED;
  }

  (*pParser)->setFeature( XMLUni::fgDOMNamespaces, true );
  (*pParser)->setFeature( XMLUni::fgXercesSchema, true );
  (*pParser)->setFeature( 
XMLUni::fgXercesSchemaFullChecking, true );

  (*pParser)->setFeature( XMLUni::fgDOMValidation, true);
  (*pParser)->setFeature( 
XMLUni::fgXercesCacheGrammarFromParse, true);

   }

   try
   {
  CMyDOMErrHandler eh();
  m_arrValidationErrs.RemoveAll();

  // parseURI a blocking call. All the errors will be 
reported first if any error handler is set

  // then only the next line will be executed.
  if(bValidate == true)
 {
   (*pParser)->setErrorHandler(&eh);
   (*pParser)->loadGrammar( strSchemaFile, 
Grammar::SchemaGrammarType, true);

 }
 else
 {
(*pParser)->setErrorHandler(NULL);
 }
 *pDoc =(*pParser)->parseURI(strXMLFile);
 ...
 ...
  }
  catch(...)
  {
...
  }

  return SUCCESS;

}

Thank you in advance.

Regards,
Neetha

[jira] [Resolved] (XERCESC-1985) I get empty strings from the startElements

[Alberto Massari (JIRA)]

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

Alberto Massari resolved XERCESC-1985.
--

Resolution: Invalid

In the startElement call, you get data either in the pair uri+localname, or in 
the qname variable. If localname is always empty, it means you didn't turn on 
namespace processing and you should look to the qname

> I get empty strings from the startElements
> --
>
> Key: XERCESC-1985
> URL: https://issues.apache.org/jira/browse/XERCESC-1985
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Validating Parser (XML Schema)
>Affects Versions: 3.1.1
> Environment: Linux Ubuntu 12.04
>Reporter: Jean-Michel Richer
>Priority: Minor
>
> I have installed xerces 3.1.1 and xalan 1.11. I have developped a simple 
> Handler (inherited from DefaultHandler) but when I parse an xml file I don't 
> get the tag which should be reported by the startElement function. Here is 
> the code :
> void XMLIOHandler::startElement(const   XMLCh* consturi,
>   const   XMLCh* constlocalname,
>   const   XMLCh* constqname,
>   const   Attributes& attrs) {
>   char *element_ptr = NULL;
>   element_ptr = XMLString::transcode(localname);
>   first_element = element_ptr;
> cerr << first_element << endl;
>   XMLString::release(&element_ptr);
> }
> it always display an empty string. I really don't know how to solve this. I 
> am doing something wrong ?
> Best regards,
> JM

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Re: include files

[Alberto Massari]

Hi Tal,
in the autoconf-based build framework, the generation of the directory 
with the include files is done by the command "make install". If you add 
DESTDIR=/your/local/folder you can control where the files will be written.


Alberto

Il 31/05/2012 15:27, Shultz Tal ha scritto:


Hi,

In version 2.8, the build process copied include files to

$(XML_INC_DIR)/

In version 3.1.1 it does not happen.

Can I configure the build to copy include files?

Thanks,

Tal



“This e-mail message may contain confidential, commercial or 
privileged information that constitutes proprietary information of 
Comverse Technology or its subsidiaries. If you are not the intended 
recipient of this message, you are hereby notified that any review, 
use or distribution of this information is absolutely prohibited and 
we request that you delete all copies and contact us by e-mailing to: 
secur...@comverse.com. Thank You.”

Re: endElement called with junk characters

[Alberto Massari]

Hi,
I need to check about the second endElement call, but your XML is 
invalid as it has two root elements. Did you set up Xerces to proceed 
also in case of fatal errors?


Alberto

Il 01/06/2012 12:48, SonalG ha scritto:

Hello,

I have overridden SAX parser methods startElement, endElement and
characters.
In characters method i am concatenating values since it may be called
multiple times.

My sample XML looks like following:



 MOC
 1
 2


 MTC
 2
 1


I am treating the fields enclosed within  to be one record.
The problem I am facing is when the endElement is called for the first
, it also immediately calls endElement again with junk characters
(there is no StartElement called).
And then it gives segmentation fault.
What I expect is it to call start element for the next.

What could be the problem with the parser or handling of startElement and
endElement methods?



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Closed] (XERCESC-1950) Build-in UCS4 transcoder does not respect endianess

[Alberto Massari (JIRA)]

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

Alberto Massari closed XERCESC-1950.


   Resolution: Cannot Reproduce
Fix Version/s: (was: 3.1.2)
   (was: 3.2.0)

I tested a modified version of your file (Xerces now doesn't serialize invalid 
XML characters, so my sample contained a 각 reference), but the output 
files I get back are different.

Looking at them with a binary editor, they show either 01 AC 00 00 (little 
endian) or 00 00 AC 01 (big endian)

> Build-in UCS4 transcoder does not respect endianess
> ---
>
> Key: XERCESC-1950
> URL: https://issues.apache.org/jira/browse/XERCESC-1950
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 3.1.1
> Environment: any
>Reporter: Boris Kolpackov
> Attachments: test.xml
>
>
> Built-in UCS4 transcoder does not respect endianess of the requested 
> encoding. Try this on the attached test file:
> DOMPrint -wenc=UCS-4LE -wfile=le.xml test.xml
> DOMPrint -wenc=UCS-4BE -wfile=be.xml test.xml
> The resulting two files will have the same representations for "long" 
> characters, little-endian if run on LE machine, and big-endian if run on a BE 
> machine. The UTF-32 transcoder doesn't seem to have this problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

[jira] [Closed] (XERCESC-1953) extra newline after declaration in 1st use of DOMWriter

[Alberto Massari (JIRA)]

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

Alberto Massari closed XERCESC-1953.


Resolution: Won't Fix

The 2.x branch will not be updated anymore

> extra newline after declaration in 1st use of DOMWriter
> ---
>
> Key: XERCESC-1953
> URL: https://issues.apache.org/jira/browse/XERCESC-1953
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: DOM
>Affects Versions: 2.8.0
> Environment: Solaris 10
>Reporter: tommy klehr
>Priority: Minor
>
> the sample program produces different output from DOMWriter although it's 
> using the same input.
> The first output has an extra newline after the declaration.  The second 
> output has the document element on the same line as the declaration.
> -
> [mynah63.dev.sol10] $ ./tc
> impl = 4df4c
> theSerializer = 58764
> can set it to discarddefaultcontent
> can set it to formatprettyprint
> rc from writeNote() = 1
> value = 
> '
>  
>  Tove 
>   Jani
>   Reminder
>   Dear
>   Don't forget me this weekend! 
> 
> '
> next take...
> impl = 4df4c
> theSerializer = 5a144
> can set it to discarddefaultcontent
> can set it to formatprettyprint
> rc from writeNote() = 1
> value = 
> ' 
>  Tove 
>   Jani
>   Reminder
>   Dear
>   Don't forget me this weekend! 
> 
> '
> $ 
> -
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> //These includes are for converting XML document into String
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> //#include 
> //For Xerces DOM usage
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> //#include 
> #include 
> #include 
> #include  // This is needed for 
> const LocalFileInputSource  theInputSource(theFileName.c_str());
> #include  // This is needed for 
> const MemBufInputSource  theInputSource(theFileName.c_str());
> #include 
> #include 
> //#include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> XALAN_USING_STD(cerr)
> XALAN_USING_STD(endl)
> XALAN_USING_STD(ostream)
> XALAN_USING_STD(ifstream)
> XALAN_USING_XALAN(XalanDocument)
> XALAN_USING_XALAN(XPathEvaluator)
> XALAN_USING_XALAN(XalanDOMString)
> XALAN_USING_XALAN(XalanSourceTreeInit)
> XALAN_USING_XALAN(XercesDOMSupport)
> XALAN_USING_XALAN(XercesParserLiaison)
> XALAN_USING_XALAN(XalanVector)
> XALAN_USING_XALAN(ExecutionContext)
> XALAN_USING_XALAN(MemoryManagerType)
> //For Xerces DOM usage
> XALAN_USING_XERCES(XMLPlatformUtils)
> XALAN_USING_XERCES(DOMNode)
> XALAN_USING_XERCES(DOMNamedNodeMap)
> XALAN_USING_XERCES(XMLString)
> XALAN_USING_XERCES(DOMImplementation)
> XALAN_USING_XERCES(DOMImplementationRegistry)
> XALAN_USING_XERCES(DOMWriter)
> XALAN_USING_XERCES(DOMImplementationLS)
> XALAN_USING_XERCES(XMLUni)
> //XALAN_USING_XERCES(DOMWriterFilter)
> XALAN_USING_XERCES(DOMErrorHandler)
> XALAN_USING_XERCES(XMLFormatTarget)
> //XALAN_USING_XERCES(DOMWriterFilter)
> XALAN_USING_XERCES(LocalFileInputSource) //const LocalFileInputSource  
> theInputSource(theFileName.c_str());
> XALAN_USING_XERCES(MemBufInputSource) 
> XALAN_USING_XERCES(MemBufFormatTarget)
> XALAN_USING_XERCES(XMLException)
> XALAN_USING_XERCES(DOMException)
> XALAN_USING_XERCES(DOMNodeFilter)
>   XALAN_USING_XERCES(LocalFileFormatTarget)
> //For XPath
> XALAN_USING_XALAN(XPathEvaluator)
> XALAN_USING_XALAN(XObjectPtr)
> XALAN_USING_XALAN(XalanNode)
> XALAN_USING_XALAN(XalanElement)
> XALAN_USING_XALAN(XalanDOMException)
> XALAN_USING_XALAN(XalanXPathException)
> XALAN_USING_XALAN(XPathParserException)
> XALAN_USING_XALAN(NodeRefList)
> //For Transformer
> XALAN_USING_XALAN(XalanCompiledStylesheet)
> XALAN_USING_XALAN(XalanDOMString)
> XALAN_USING_XALAN(X