[jira] [Commented] (XERCESC-2070) Ability to disable DTD processing

[Scott Cantor (JIRA)]

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

Scott Cantor commented on XERCESC-2070:
---

Environment hack is ported to trunk, r1747620.

Leaving open to add the parser feature fix.

> Ability to disable DTD processing
> -
>
> Key: XERCESC-2070
> URL: https://issues.apache.org/jira/browse/XERCESC-2070
> Project: Xerces-C++
>  Issue Type: Improvement
>  Components: Validating Parser (DTD)
>Reporter: Scott Cantor
>Assignee: Scott Cantor
> Fix For: 3.2.0, 3.1.4
>
>
> We should provide a way for applications that don't need DTDs to be insulated 
> from bugs in that code.
> Trunk could do this pretty easily with the same property URI that Xerces-J 
> and Java use for this.
> To do it without an ABI change, I'm going to patch in an environment variable 
> check. It's ugly, but this is a problem of such magnitude that I don't see 
> any other option, particularly given the lack of resources devoted to the 
> project.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (XERCESC-2070) Ability to disable DTD processing

[Scott Cantor (JIRA)]

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

Scott Cantor reassigned XERCESC-2070:
-

Assignee: Scott Cantor

> Ability to disable DTD processing
> -
>
> Key: XERCESC-2070
> URL: https://issues.apache.org/jira/browse/XERCESC-2070
> Project: Xerces-C++
>  Issue Type: Improvement
>  Components: Validating Parser (DTD)
>Reporter: Scott Cantor
>Assignee: Scott Cantor
> Fix For: 3.2.0, 3.1.4
>
>
> We should provide a way for applications that don't need DTDs to be insulated 
> from bugs in that code.
> Trunk could do this pretty easily with the same property URI that Xerces-J 
> and Java use for this.
> To do it without an ABI change, I'm going to patch in an environment variable 
> check. It's ugly, but this is a problem of such magnitude that I don't see 
> any other option, particularly given the lack of resources devoted to the 
> project.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (XERCESC-2069) Stack overflow in 3.1.3

[Scott Cantor (JIRA)]

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

Scott Cantor resolved XERCESC-2069.
---
Resolution: Fixed

Applied to trunk, r1799527.

I'd like to take the time to expose the depth limit as an option somehow, but I 
don't have the time or knowledge of the code to try that.

> Stack overflow in 3.1.3
> ---
>
> Key: XERCESC-2069
> URL: https://issues.apache.org/jira/browse/XERCESC-2069
> Project: Xerces-C++
>  Issue Type: Bug
>Affects Versions: 3.1.3
> Environment: Ubuntu 15.10 x86_64, clang 3.6
>Reporter: Brandon Perry
>Assignee: Scott Cantor
> Fix For: 3.2.0, 3.1.4
>
>
> I don't see an obvious way to upload an example file, so linked is a secret 
> Github \
> gist with a file used to reproduce the below ASan result, using the 
> StdInParse binary \
> shipped with the xerces source code.
> https://gist.github.com/brandonprry/e5ddbcc3d768a5c0f729e904f77a297b 
> ASan:
> ==26604==ERROR: AddressSanitizer: stack-overflow on address 0x7ffc2f7d9998 
> (pc 0x004a974a bp 0x7ffc2f7da210 sp 0x7ffc2f7d99a0 T0)
> #0 0x4a9749 in __asan_memcpy (/usr/local/bin/StdInParse+0x4a9749)
> #1 0x7fecc04d235a in xercesc_3_1::XMLBuffer::append(unsigned short 
> const*, unsigned long) (/usr/lib/libxerces-c-3.1.so+0x2c835a)
> #2 0x7fecc0b53abb in 
> xercesc_3_1::XMLReader::getName(xercesc_3_1::XMLBuffer&, bool) 
> (/usr/lib/libxerces-c-3.1.so+0x949abb)
> #3 0x7fecc09bdaa1 in 
> xercesc_3_1::ReaderMgr::getName(xercesc_3_1::XMLBuffer&) 
> (/usr/lib/libxerces-c-3.1.so+0x7b3aa1)
> #4 0x7fecc0f08974 in 
> xercesc_3_1::DTDScanner::scanChildren(xercesc_3_1::DTDElementDecl const&, 
> xercesc_3_1::XMLBuffer&) (/usr/lib/libxerces-c-3.1.so+0xcfe974)
> #5 0x7fecc0f0aa79 in 
> xercesc_3_1::DTDScanner::scanChildren(xercesc_3_1::DTDElementDecl const&, 
> xercesc_3_1::XMLBuffer&) (/usr/lib/libxerces-c-3.1.so+0xd00a79)
> #6 0x7fecc0f0aa79 in 
> xercesc_3_1::DTDScanner::scanChildren(xercesc_3_1::DTDElementDecl const&, 
> xercesc_3_1::XMLBuffer&) (/usr/lib/libxerces-c-3.1.so+0xd00a79)
> #7 0x7fecc0f0aa79 in 
> xercesc_3_1::DTDScanner::scanChildren(xercesc_3_1::DTDElementDecl const&, 
> xercesc_3_1::XMLBuffer&) (/usr/lib/libxerces-c-3.1.so+0xd00a79)
> #8 0x7fecc0f0aa79 in 
> xercesc_3_1::DTDScanner::scanChildren(xercesc_3_1::DTDElementDecl const&, 
> xercesc_3_1::XMLBuffer&) (/usr/lib/libxerces-c-3.1.so+0xd00a79)
> #9 0x7fecc0f0aa79 in 
> xercesc_3_1::DTDScanner::scanChildren(xercesc_3_1::DTDElementDecl const&, 
> xercesc_3_1::XMLBuffer&) (/usr/lib/libxerces-c-3.1.so+0xd00a79)
> #10 0x7fecc0f0aa79 in 
> xercesc_3_1::DTDScanner::scanChildren(xercesc_3_1::DTDElementDecl const&, 
> xercesc_3_1::XMLBuffer&) (/usr/lib/libxerces-c-3.1.so+0xd00a79)
> #11 0x7fecc0f0aa79 in 
> xercesc_3_1::DTDScanner::scanChildren(xercesc_3_1::DTDElementDecl const&, 
> xercesc_3_1::XMLBuffer&) (/usr/lib/libxerces-c-3.1.so+0xd00a79)
> #12 0x7fecc0f0aa79 in 
> xercesc_3_1::DTDScanner::scanChildren(xercesc_3_1::DTDElementDecl const&, 
> xercesc_3_1::XMLBuffer&) (/usr/lib/libxerces-c-3.1.so+0xd00a79)
> #13 0x7fecc0f0aa79 in 
> xercesc_3_1::DTDScanner::scanChildren(xercesc_3_1::DTDElementDecl const&, 
> xercesc_3_1::XMLBuffer&) (/usr/lib/libxerces-c-3.1.so+0xd00a79)
> #14 0x7fecc0f0aa79 in 
> xercesc_3_1::DTDScanner::scanChildren(xercesc_3_1::DTDElementDecl const&, 
> xercesc_3_1::XMLBuffer&) (/usr/lib/libxerces-c-3.1.so+0xd00a79)
> #15 0x7fecc0f0aa79 in 
> xercesc_3_1::DTDScanner::scanChildren(xercesc_3_1::DTDElementDecl const&, 
> xercesc_3_1::XMLBuffer&) (/usr/lib/libxerces-c-3.1.so+0xd00a79)
> #16 0x7fecc0f0aa79 in 
> xercesc_3_1::DTDScanner::scanChildren(xercesc_3_1::DTDElementDecl const&, 
> xercesc_3_1::XMLBuffer&) (/usr/lib/libxerces-c-3.1.so+0xd00a79)
> #17 0x7fecc0f0aa79 in 
> xercesc_3_1::DTDScanner::scanChildren(xercesc_3_1::DTDElementDecl const&, 
> xercesc_3_1::XMLBuffer&) (/usr/lib/libxerces-c-3.1.so+0xd00a79)
> #18 0x7fecc0f0aa79 in 
> xercesc_3_1::DTDScanner::scanChildren(xercesc_3_1::DTDElementDecl const&, 
> xercesc_3_1::XMLBuffer&) (/usr/lib/libxerces-c-3.1.so+0xd00a79)
> #19 0x7fecc0f0aa79 in 
> xercesc_3_1::DTDScanner::scanChildren(xercesc_3_1::DTDElementDecl const&, 
> xercesc_3_1::XMLBuffer&) (/usr/lib/libxerces-c-3.1.so+0xd00a79)
> #20 0x7fecc0f0aa79 in 
> xercesc_3_1::DTDScanner::scanChildren(xercesc_3_1::DTDElementDecl const&, 
> xercesc_3_1::XMLBuffer&) (/usr/lib/libxerces-c-3.1.so+0xd00a79)
> #21 0x7fecc0f0aa79 in 
> xercesc_3_1::DTDScanner::scanChildren(xercesc_3_1::DTDElementDecl const&, 
> xercesc_3_1::XMLBuffer&) (/usr/lib/libxerces-c-3.1.so+0xd00a79)
> #22 0x7fecc0f0aa79 in 
> xercesc_3_1::DTDScanner::scanChildren(xercesc_3_1::DTDElementDecl const&, 
> xercesc_3_1::XMLBuffer&) (/usr/lib/libxerces-c-3.1.so+0xd00a79)
> 

[jira] [Resolved] (XERCESC-2066) Exception handling mistake in DTDScanner

[Scott Cantor (JIRA)]

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

Scott Cantor resolved XERCESC-2066.
---
Resolution: Fixed

Applied to trunk, r1799527.

> Exception handling mistake in DTDScanner
> 
>
> Key: XERCESC-2066
> URL: https://issues.apache.org/jira/browse/XERCESC-2066
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Validating Parser (DTD)
>Affects Versions: 3.1.0, 3.1.1, 3.1.2, 3.1.3
>Reporter: Scott Cantor
>Assignee: Scott Cantor
> Fix For: 3.2.0, 3.1.4
>
>
> Index: src/xercesc/validators/DTD/DTDScanner.cpp
> ==The DTDScanner 
> fails to account for the fact that peeking characters in the XMLReader class 
> can raise an exception if an invalid character is encountered, and the 
> exception crosses stack frames in an unsafe way that causes a higher level 
> exception handler to access an already-freed object.
> The proposed patch below traps the exception locally and records the parser 
> error in the appropriate frame.
> We should also review the code for other calls to the XMLReader methods that 
> can throw.
> {code}
> --- src/xercesc/validators/DTD/DTDScanner.cpp (revision 1741478)
> +++ src/xercesc/validators/DTD/DTDScanner.cpp (working copy)
> @@ -2509,7 +2509,15 @@
>  {
>  while (true)
>  {
> -const XMLCh nextCh = fReaderMgr->peekNextChar();
> +XMLCh nextCh;
> +
> +try {
> +nextCh = fReaderMgr->peekNextChar();
> +}
> +catch (XMLException& ex) {
> +fScanner->emitError(XMLErrs::XMLException_Fatal, 
> ex.getCode(), ex.getMessage(), NULL, NULL);
> +nextCh = chNull;
> +}
>  
>  if (!nextCh)
>  {
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (XERCESC-2065) Carriage return entities are not handled properly

[Scott Cantor (JIRA)]

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

Scott Cantor resolved XERCESC-2065.
---
Resolution: Fixed

> Carriage return entities are not handled properly
> -
>
> Key: XERCESC-2065
> URL: https://issues.apache.org/jira/browse/XERCESC-2065
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: DOM, Non-Validating Parser, SAX/SAX2
>Affects Versions: 3.1.3
>Reporter: Scott Cantor
>Assignee: Scott Cantor
>Priority: Critical
> Fix For: 3.2.0, 3.1.4
>
> Attachments: xercesc-2065.patch
>
>
> Documents with CR entities don't seem to round trip properly in the parser if 
> you parse them and then serialize them. It's possible the bug is in the 
> serializer because signed documents don't end up with corrupt signatures, but 
> that may be due to insufficient testing as of yet.
> A simple example:
> {code}
> 
> 
>textmore
> 
> {code}
> Running that through DOMPrint or SAX2Print:
> {code}
> 
> more
> 
> {code}
> Notice the CR entity is removed, but also all of the characters immediately 
> in front of it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (XERCESC-2065) Carriage return entities are not handled properly

[Scott Cantor (JIRA)]

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

Scott Cantor commented on XERCESC-2065:
---

Applied to trunk, r1799526.

> Carriage return entities are not handled properly
> -
>
> Key: XERCESC-2065
> URL: https://issues.apache.org/jira/browse/XERCESC-2065
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: DOM, Non-Validating Parser, SAX/SAX2
>Affects Versions: 3.1.3
>Reporter: Scott Cantor
>Assignee: Scott Cantor
>Priority: Critical
> Fix For: 3.2.0, 3.1.4
>
> Attachments: xercesc-2065.patch
>
>
> Documents with CR entities don't seem to round trip properly in the parser if 
> you parse them and then serialize them. It's possible the bug is in the 
> serializer because signed documents don't end up with corrupt signatures, but 
> that may be due to insufficient testing as of yet.
> A simple example:
> {code}
> 
> 
>textmore
> 
> {code}
> Running that through DOMPrint or SAX2Print:
> {code}
> 
> more
> 
> {code}
> Notice the CR entity is removed, but also all of the characters immediately 
> in front of it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (XERCESC-2059) Typo in XMLUni::fgUnknownURIName constant

[Scott Cantor (JIRA)]

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

Scott Cantor reassigned XERCESC-2059:
-

Assignee: Scott Cantor

> Typo in XMLUni::fgUnknownURIName constant
> -
>
> Key: XERCESC-2059
> URL: https://issues.apache.org/jira/browse/XERCESC-2059
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Miscellaneous
>Affects Versions: 3.1.0, 3.1.1, 3.1.2
>Reporter: Scott Cantor
>Assignee: Scott Cantor
>Priority: Trivial
> Fix For: 3.2.0, 3.1.3
>
>
> Missing an 'n' in Unknown



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (XERCESC-2059) Typo in XMLUni::fgUnknownURIName constant

[Scott Cantor (JIRA)]

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

Scott Cantor resolved XERCESC-2059.
---
Resolution: Fixed

Applied to trunk, r1799525.

> Typo in XMLUni::fgUnknownURIName constant
> -
>
> Key: XERCESC-2059
> URL: https://issues.apache.org/jira/browse/XERCESC-2059
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Miscellaneous
>Affects Versions: 3.1.0, 3.1.1, 3.1.2
>Reporter: Scott Cantor
>Assignee: Scott Cantor
>Priority: Trivial
> Fix For: 3.2.0, 3.1.3
>
>
> Missing an 'n' in Unknown



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (XERCESC-2044) Code analysis revealed multiple potential NULL derefence conditions (currently unconfirmed)

[Scott Cantor (JIRA)]

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

Scott Cantor resolved XERCESC-2044.
---
Resolution: Fixed

Applied to trunk, r1799522.

> Code analysis revealed multiple potential NULL derefence conditions 
> (currently unconfirmed)
> ---
>
> Key: XERCESC-2044
> URL: https://issues.apache.org/jira/browse/XERCESC-2044
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Miscellaneous
>Affects Versions: 3.1.1
>Reporter: Int3
>Assignee: Scott Cantor
> Fix For: 3.2.0, 3.1.2
>
> Attachments: DTDScanner.patch, IGXMLScanner.patch, 
> InMemMsgLoader.patch, XSObjectFactory.patch
>
>
> src/xercesc/util/MsgLoaders/InMemory/InMemMsgLoader.cpp
> If fMsgDomain doesn't match one of the 4 else clauses, it could dereference 
> null at line 106
> src/xercesc/internal/IGXMLScanner.cpp
> The !elemDecl check on line 2383 appears to be missing a final else clause to 
> catch unknown grammar types.
> src/xercesc/internal/XSObjectFactory.cpp
> If the xsMultiFacetList is not allocated at line 840, there are no obvious 
> checks later in the function to ensure it is not dereferenced
> src/xercesc/validators/DTD/DTDScanner.cpp
> If the first branch followed is  "else if 
> (fReaderMgr->skippedChar(chCloseParen))" at line 1210, lastNode can 
> potentially dereference a NULL at line 1225



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (XERCESC-2044) Code analysis revealed multiple potential NULL derefence conditions (currently unconfirmed)

[Scott Cantor (JIRA)]

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

Scott Cantor reassigned XERCESC-2044:
-

Assignee: Scott Cantor  (was: Boris Kolpackov)

> Code analysis revealed multiple potential NULL derefence conditions 
> (currently unconfirmed)
> ---
>
> Key: XERCESC-2044
> URL: https://issues.apache.org/jira/browse/XERCESC-2044
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Miscellaneous
>Affects Versions: 3.1.1
>Reporter: Int3
>Assignee: Scott Cantor
> Fix For: 3.1.2, 3.2.0
>
> Attachments: DTDScanner.patch, IGXMLScanner.patch, 
> InMemMsgLoader.patch, XSObjectFactory.patch
>
>
> src/xercesc/util/MsgLoaders/InMemory/InMemMsgLoader.cpp
> If fMsgDomain doesn't match one of the 4 else clauses, it could dereference 
> null at line 106
> src/xercesc/internal/IGXMLScanner.cpp
> The !elemDecl check on line 2383 appears to be missing a final else clause to 
> catch unknown grammar types.
> src/xercesc/internal/XSObjectFactory.cpp
> If the xsMultiFacetList is not allocated at line 840, there are no obvious 
> checks later in the function to ensure it is not dereferenced
> src/xercesc/validators/DTD/DTDScanner.cpp
> If the first branch followed is  "else if 
> (fReaderMgr->skippedChar(chCloseParen))" at line 1210, lastNode can 
> potentially dereference a NULL at line 1225



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (XERCESC-1926) IGXMLScanner can fail to properly set its XSModel.

[Scott Cantor (JIRA)]

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

Scott Cantor resolved XERCESC-1926.
---
Resolution: Fixed

Applied to trunk, r1799520.

> IGXMLScanner can fail to properly set its XSModel.
> --
>
> Key: XERCESC-1926
> URL: https://issues.apache.org/jira/browse/XERCESC-1926
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Validating Parser (XML Schema)
>Affects Versions: 3.0.0, 3.0.1, 3.1.0, 3.1.1
>Reporter: John Keeping
>Assignee: Scott Cantor
> Fix For: 3.2.0, 3.1.2
>
> Attachments: xerces-model-update.patch
>
>
> If an IGXMLScanner is used for a document with no schema and then reset to 
> scan a document with a schema the model is not set correctly.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (XERCESC-1926) IGXMLScanner can fail to properly set its XSModel.

[Scott Cantor (JIRA)]

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

Scott Cantor updated XERCESC-1926:
--
Affects Version/s: 3.0.0
   3.0.1
   3.1.0
   3.1.1

> IGXMLScanner can fail to properly set its XSModel.
> --
>
> Key: XERCESC-1926
> URL: https://issues.apache.org/jira/browse/XERCESC-1926
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Validating Parser (XML Schema)
>Affects Versions: 3.0.0, 3.0.1, 3.1.0, 3.1.1
>Reporter: John Keeping
> Fix For: 3.1.2, 3.2.0
>
> Attachments: xerces-model-update.patch
>
>
> If an IGXMLScanner is used for a document with no schema and then reset to 
> scan a document with a schema the model is not set correctly.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (XERCESC-1926) IGXMLScanner can fail to properly set its XSModel.

[Scott Cantor (JIRA)]

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

Scott Cantor reassigned XERCESC-1926:
-

Assignee: Scott Cantor

> IGXMLScanner can fail to properly set its XSModel.
> --
>
> Key: XERCESC-1926
> URL: https://issues.apache.org/jira/browse/XERCESC-1926
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Validating Parser (XML Schema)
>Affects Versions: 3.0.0, 3.0.1, 3.1.0, 3.1.1
>Reporter: John Keeping
>Assignee: Scott Cantor
> Fix For: 3.1.2, 3.2.0
>
> Attachments: xerces-model-update.patch
>
>
> If an IGXMLScanner is used for a document with no schema and then reset to 
> scan a document with a schema the model is not set correctly.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (XERCESC-1925) Wrong temporary token type causes regex construction to fail

[Scott Cantor (JIRA)]

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

Scott Cantor reassigned XERCESC-1925:
-

Assignee: Scott Cantor

> Wrong temporary token type causes regex construction to fail
> 
>
> Key: XERCESC-1925
> URL: https://issues.apache.org/jira/browse/XERCESC-1925
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 3.0.0, 3.0.1, 3.1.0, 3.1.1
>Reporter: John Keeping
>Assignee: Scott Cantor
> Fix For: 3.1.2, 3.2.0
>
> Attachments: xerces-range-token-merge.patch
>
>
> When checking for token overlap in a regular expression a temporary range 
> token is constructed and merged with another range token. This temporary 
> token has type Token::T_RANGE so the merge fails if the actual token is of 
> type Token::T_NRANGE.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (XERCESC-1925) Wrong temporary token type causes regex construction to fail

[Scott Cantor (JIRA)]

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

Scott Cantor updated XERCESC-1925:
--
Affects Version/s: 3.0.0
   3.0.1
   3.1.0
   3.1.1

> Wrong temporary token type causes regex construction to fail
> 
>
> Key: XERCESC-1925
> URL: https://issues.apache.org/jira/browse/XERCESC-1925
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 3.0.0, 3.0.1, 3.1.0, 3.1.1
>Reporter: John Keeping
>Assignee: Scott Cantor
> Fix For: 3.1.2, 3.2.0
>
> Attachments: xerces-range-token-merge.patch
>
>
> When checking for token overlap in a regular expression a temporary range 
> token is constructed and merged with another range token. This temporary 
> token has type Token::T_RANGE so the merge fails if the actual token is of 
> type Token::T_NRANGE.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (XERCESC-1925) Wrong temporary token type causes regex construction to fail

[Scott Cantor (JIRA)]

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

Scott Cantor resolved XERCESC-1925.
---
Resolution: Fixed

Ported from branch, r1662893.

> Wrong temporary token type causes regex construction to fail
> 
>
> Key: XERCESC-1925
> URL: https://issues.apache.org/jira/browse/XERCESC-1925
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 3.0.0, 3.0.1, 3.1.0, 3.1.1
>Reporter: John Keeping
>Assignee: Scott Cantor
> Fix For: 3.2.0, 3.1.2
>
> Attachments: xerces-range-token-merge.patch
>
>
> When checking for token overlap in a regular expression a temporary range 
> token is constructed and merged with another range token. This temporary 
> token has type Token::T_RANGE so the merge fails if the actual token is of 
> type Token::T_NRANGE.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (XERCESC-1951) Missing Libs.private in the xerces-c pkg-config file

[Scott Cantor (JIRA)]

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

Scott Cantor resolved XERCESC-1951.
---
Resolution: Fixed
  Assignee: Scott Cantor

> Missing Libs.private in the xerces-c pkg-config file
> 
>
> Key: XERCESC-1951
> URL: https://issues.apache.org/jira/browse/XERCESC-1951
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 3.1.1
> Environment: MinGW cross compiling
>Reporter: Volker Grabsch
>Assignee: Scott Cantor
> Fix For: 3.2.0, 3.1.2
>
> Attachments: xerces-fix-pkgconfig.patch
>
>
> When compiling Xerces statically with libCURL support, the command
> pkg-config xerces-c --static --libs
> does not output the CURL lib and its dependencies. This finally leads to 
> linker errors.
> The attached patch fixed this issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (XERCESC-1951) Missing Libs.private in the xerces-c pkg-config file

[Scott Cantor (JIRA)]

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

Scott Cantor commented on XERCESC-1951:
---

Applied to trunk, r1799513

> Missing Libs.private in the xerces-c pkg-config file
> 
>
> Key: XERCESC-1951
> URL: https://issues.apache.org/jira/browse/XERCESC-1951
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 3.1.1
> Environment: MinGW cross compiling
>Reporter: Volker Grabsch
> Fix For: 3.1.2, 3.2.0
>
> Attachments: xerces-fix-pkgconfig.patch
>
>
> When compiling Xerces statically with libCURL support, the command
> pkg-config xerces-c --static --libs
> does not output the CURL lib and its dependencies. This finally leads to 
> linker errors.
> The attached patch fixed this issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: Integrating CMake support for xerces

[Roger Leigh]

On 21/06/17 14:53, Vitaly Prapirny wrote:

Roger Leigh wrote on 21/06/2017 13:58:

Sorry, too hasty.  Please try this revised patch which actually works.


CMake worked without error, but compilation failed just the same way as 
in my previous message.


That line (PlatformUtils.cpp:27) is

#if HAVE_CONFIG_H
#   include 
#endif

so it either can't cope with "#if xxx" (which is used in many places), 
or the error is in the generated "config.h".  I'm afraid you'll need to 
identify the cause of the error here.  Can you include config.h in a 
single test file like this:


#if HAVE_CONFIG_H
#   include 
#endif

int main()
{}

with or without the #if/endif?  If you can pinpoint where the problem 
is, we can look at further fixes.



Regards,
Roger

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

Re: Integrating CMake support for xerces

[Vitaly Prapirny]

Roger Leigh wrote on 21/06/2017 13:58:

Sorry, too hasty.  Please try this revised patch which actually works.


CMake worked without error, but compilation failed just the same way as 
in my previous message.


Good luck!
   Vitaly

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

[jira] [Commented] (XERCESC-2102) Documentation is not generatable on modern systems

[Scott Cantor (JIRA)]

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

Scott Cantor commented on XERCESC-2102:
---

I would agree that markdown would be preferable to anything involving a 
publishing toolchain. The challenge here is the existing site and all the 
conversion required and the overlap with Xerces-J.

Whereas at the moment, modulo the Java 6 issue, I do have accurate instructions 
for building the site and have gotten the overall set of files needing to be 
tweaked to a fair minimum when releases get done.

I don't think we should spend the effort to convert unless the result at the 
end doesn't involve having to check the site's files into svn and require any 
real work when releases are done. Bump a version and move on should be the only 
*required* step. Otherwise security fixes become a mess of unrelated work when 
the only real goal is "get fix out".

The Santuario project has a cwiki site set up that auto-publishes to the ASF 
web site and while the look and feel may be awful, that is of no concern since 
the docs are out of date and useless anyway. It minimizes release effort.

> Documentation is not generatable on modern systems
> --
>
> Key: XERCESC-2102
> URL: https://issues.apache.org/jira/browse/XERCESC-2102
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Roger Leigh
>
> The "stylebook" documentation format relies upon {{stylebook-1.0-b2.jar}}.  
> Unfortunately this tool appears to no longer be developed and it no longer 
> works with contemporary JREs due to relying upon 
> {com.sun.image.codec.jpeg.JPEGCodec} which is no longer present.  It's 
> achievable by trying to find a Java 1.6 or earlier JRE, but this is becoming 
> increasingly difficult to make work.
> Was there ever a migration path from slidebook to any other format which is 
> currently supported?
> Would there be any interest in moving to a contemporary documentation format, 
> and if so are there any preferred formats?  At work we use Sphinx.  I'd be 
> happy to spend a few hours converting it to this or some other format which 
> is currently supported.
> Regards,
> Roger
> {noformat}
> % make createdocs   
> [StyleBook] Overriding 
> targetDirectory="/home/rleigh/code/xerces-svn-trunk/doc/html" (Old=".")
> [StyleBook] Project URL: "sbk:/sources/xerces-c_book.xml"
> [BasicEngine] Initializing
> [Loader] Parsing Project file
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/book2project.xsl"
> [XalanProcessor] Applying XSL sheet 
> "sbk:/style/stylesheets/directory2project.xsl"
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (1)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (2)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (3)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (4)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (5)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (6)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (7)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (8)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (9)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (10)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (11)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (12)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> 

Re: Integrating CMake support for xerces

[Roger Leigh]

On 21/06/17 11:17, Roger Leigh wrote:



On 21/06/17 10:46, Vitaly Prapirny wrote:

Roger Leigh wrote on 21/06/2017 12:20:

On 21/06/17 08:48, Vitaly Prapirny wrote:
I've got an error while running cmake with "Borland Makefiles" 
generator and Borland C++ Builder 5 compiler. Is BCB5 still supported?


It's not a combination I've personally tested, but I can't see any 
evidence that it shouldn't work.


What are the errors you are seeing?  Maybe it just needs a few minor 
tweaks to our cmake logic.
I've attached log files to the 
https://issues.apache.org/jira/browse/XERCESC-2077


Thanks.  This was a problem with the int type check fallbacks.  Please 
see the attached patch or this github branch: 
https://github.com/rleigh-codelibre/xerces-c/tree/cmake-int-fallback


Sorry, too hasty.  Please try this revised patch which actually works.


Roger
>From 294248062d2f2843895c1a62599ebbef4f4e0985 Mon Sep 17 00:00:00 2001
From: Roger Leigh 
Date: Wed, 21 Jun 2017 11:12:17 +0100
Subject: [PATCH] cmake: XercesIntTypes: Correct signed types and variable
 names

---
 cmake/XercesIntTypes.cmake | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/cmake/XercesIntTypes.cmake b/cmake/XercesIntTypes.cmake
index 3390febf7..c840b0010 100644
--- a/cmake/XercesIntTypes.cmake
+++ b/cmake/XercesIntTypes.cmake
@@ -70,13 +70,13 @@ else()
 endif()
 
 # Check type sizes
-check_type_size("short"  SIZEOF_SHORT)
+check_type_size("signed short"   SIZEOF_SHORT)
 check_type_size("unsigned short" SIZEOF_UNSIGNED_SHORT)
-check_type_size("int"SIZEOF_INT)
+check_type_size("signed int" SIZEOF_INT)
 check_type_size("unsigned int"   SIZEOF_UNSIGNED_INT)
-check_type_size("long"   SIZEOF_LONG)
+check_type_size("signed long"SIZEOF_LONG)
 check_type_size("unsigned long"  SIZEOF_UNSIGNED_LONG)
-check_type_size("long long"  SIZEOF_LONG_LONG)
+check_type_size("signed long long"   SIZEOF_LONG_LONG)
 check_type_size("unsigned long long" SIZEOF_UNSIGNED_LONG_LONG)
 check_type_size("__int64"SIZEOF___INT64)
 check_type_size("unsigned __int64"   SIZEOF_UNSIGNED__INT64)
@@ -100,7 +100,7 @@ if(HAVE_CSTDINT OR HAVE_STDINT_H OR HAVE_INTTYPES_H)
   set(XERCES_U64BIT_INT "uint64_t")
 else()
   # Fallback to basic language types
-  if(SIZEOF_SIGNED_SHORT EQUAL 2)
+  if(SIZEOF_SHORT EQUAL 2)
 set(XERCES_S16BIT_INT "signed short")
   elseif(SIZEOF_INT EQUAL 2)
 set(XERCES_S16BIT_INT "int")
@@ -116,9 +116,9 @@ else()
 message(FATAL_ERROR "Couldn't find an unsigned 16-bit type")
   endif()
 
-  if(SIZEOF_SIGNED_INT EQUAL 4)
+  if(SIZEOF_INT EQUAL 4)
 set(XERCES_S32BIT_INT "signed int")
-  elseif(SIZEOF_SIGNED_LONG EQUAL 4)
+  elseif(SIZEOF_LONG EQUAL 4)
 set(XERCES_S32BIT_INT "signed long")
   else()
 message(FATAL_ERROR "Couldn't find a signed 32-bit type")
@@ -133,11 +133,11 @@ else()
   endif()
 
   if(SIZEOF_INT EQUAL 8)
-set(XERCES_S64BIT_INT "int")
+set(XERCES_S64BIT_INT "signed int")
   elseif(SIZEOF_LONG EQUAL 8)
-set(XERCES_S64BIT_INT "long")
+set(XERCES_S64BIT_INT "signed long")
   elseif(SIZEOF_LONG_LONG EQUAL 8)
-set(XERCES_S64BIT_INT "long long")
+set(XERCES_S64BIT_INT "signed long long")
   elseif(SIZEOF___INT64 EQUAL 8)
 set(XERCES_S64BIT_INT "__int64")
   else()
-- 
2.13.1



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

Re: Integrating CMake support for xerces

[Vitaly Prapirny]

Roger Leigh wrote on 21/06/2017 13:17:
Thanks.  This was a problem with the int type check fallbacks. Please 
see the attached patch or this github branch: 
https://github.com/rleigh-codelibre/xerces-c/tree/cmake-int-fallback


This was a search-replace error when porting m4/xerces_int_types, and 
all the systems I've tested on all had stdint.h or cstdint, so I 
didn't notice this wasn't working.  I've switched all the types to be 
unambiguously signed, and added SIGNED_ to all the variable names 
where missing.


If you could give that a go, I'd be very interested if this works for 
you, or if you hit any other problems after this point.
CMake worked without error in that branch, but compilation failed (make 
log attached).


Good luck!
   Vitaly

MAKE Version 5.2  Copyright (c) 1987, 2000 Borland
MAKE Version 5.2  Copyright (c) 1987, 2000 Borland
MAKE Version 5.2  Copyright (c) 1987, 2000 Borland
Scanning dependencies of target xerces-c
MAKE Version 5.2  Copyright (c) 1987, 2000 Borland
[  0%] Building CXX object 
src/CMakeFiles/xerces-c.dir/xercesc/util/Base64.cpp.obj
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\Base64.cpp:
[  0%] Building CXX object 
src/CMakeFiles/xerces-c.dir/xercesc/util/BinFileInputStream.cpp.obj
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\BinFileInputStream.cpp:
[  1%] Building CXX object 
src/CMakeFiles/xerces-c.dir/xercesc/util/BinInputStream.cpp.obj
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\BinInputStream.cpp:
[  1%] Building CXX object 
src/CMakeFiles/xerces-c.dir/xercesc/util/BinMemInputStream.cpp.obj
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\BinMemInputStream.cpp:
[  1%] Building CXX object 
src/CMakeFiles/xerces-c.dir/xercesc/util/BitSet.cpp.obj
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\BitSet.cpp:
[  1%] Building CXX object 
src/CMakeFiles/xerces-c.dir/xercesc/util/DefaultPanicHandler.cpp.obj
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\DefaultPanicHandler.cpp:
[  2%] Building CXX object 
src/CMakeFiles/xerces-c.dir/xercesc/util/EncodingValidator.cpp.obj
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\EncodingValidator.cpp:
[  2%] Building CXX object 
src/CMakeFiles/xerces-c.dir/xercesc/util/HeaderDummy.cpp.obj
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\HeaderDummy.cpp:
[  2%] Building CXX object 
src/CMakeFiles/xerces-c.dir/xercesc/util/HexBin.cpp.obj
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\HexBin.cpp:
[  2%] Building CXX object 
src/CMakeFiles/xerces-c.dir/xercesc/util/KVStringPair.cpp.obj
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\KVStringPair.cpp:
[  3%] Building CXX object 
src/CMakeFiles/xerces-c.dir/xercesc/util/Mutexes.cpp.obj
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\Mutexes.cpp:
[  3%] Building CXX object 
src/CMakeFiles/xerces-c.dir/xercesc/util/PanicHandler.cpp.obj
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\PanicHandler.cpp:
[  3%] Building CXX object 
src/CMakeFiles/xerces-c.dir/xercesc/util/PlatformUtils.cpp.obj
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\PlatformUtils.cpp:
Error E2188 
E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\PlatformUtils.cpp 27: 
Expression syntax
*** 1 errors in Compile ***

** error 1 ** deleting 
src\CMakeFiles\xerces-c.dir\xercesc\util\PlatformUtils.cpp.obj

** error 1 ** deleting src\CMakeFiles\xerces-c.dir\all

** error 1 ** deleting all


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

Re: Integrating CMake support for xerces

[Roger Leigh]

On 21/06/17 10:46, Vitaly Prapirny wrote:

Roger Leigh wrote on 21/06/2017 12:20:

On 21/06/17 08:48, Vitaly Prapirny wrote:
I've got an error while running cmake with "Borland Makefiles" 
generator and Borland C++ Builder 5 compiler. Is BCB5 still supported?


It's not a combination I've personally tested, but I can't see any 
evidence that it shouldn't work.


What are the errors you are seeing?  Maybe it just needs a few minor 
tweaks to our cmake logic.
I've attached log files to the 
https://issues.apache.org/jira/browse/XERCESC-2077


Thanks.  This was a problem with the int type check fallbacks.  Please 
see the attached patch or this github branch: 
https://github.com/rleigh-codelibre/xerces-c/tree/cmake-int-fallback


This was a search-replace error when porting m4/xerces_int_types, and 
all the systems I've tested on all had stdint.h or cstdint, so I didn't 
notice this wasn't working.  I've switched all the types to be 
unambiguously signed, and added SIGNED_ to all the variable names where 
missing.


If you could give that a go, I'd be very interested if this works for 
you, or if you hit any other problems after this point.



Regards,
Roger
>From c56f25ebf6f40a68a3232d1132bb7f4953185218 Mon Sep 17 00:00:00 2001
From: Roger Leigh 
Date: Wed, 21 Jun 2017 11:12:17 +0100
Subject: [PATCH] cmake: XercesIntType: Correct signed types and variable names

---
 cmake/XercesIntTypes.cmake | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/cmake/XercesIntTypes.cmake b/cmake/XercesIntTypes.cmake
index 3390febf7..dd5ab472c 100644
--- a/cmake/XercesIntTypes.cmake
+++ b/cmake/XercesIntTypes.cmake
@@ -70,13 +70,13 @@ else()
 endif()
 
 # Check type sizes
-check_type_size("short"  SIZEOF_SHORT)
+check_type_size("signed short"   SIZEOF_SIGNED_SHORT)
 check_type_size("unsigned short" SIZEOF_UNSIGNED_SHORT)
-check_type_size("int"SIZEOF_INT)
+check_type_size("signed int" SIZEOF_SIGNED_INT)
 check_type_size("unsigned int"   SIZEOF_UNSIGNED_INT)
-check_type_size("long"   SIZEOF_LONG)
+check_type_size("signed long"SIZEOF_SIGNED_LONG)
 check_type_size("unsigned long"  SIZEOF_UNSIGNED_LONG)
-check_type_size("long long"  SIZEOF_LONG_LONG)
+check_type_size("signed long long"   SIZEOF_SIGNED_LONG_LONG)
 check_type_size("unsigned long long" SIZEOF_UNSIGNED_LONG_LONG)
 check_type_size("__int64"SIZEOF___INT64)
 check_type_size("unsigned __int64"   SIZEOF_UNSIGNED__INT64)
@@ -102,7 +102,7 @@ else()
   # Fallback to basic language types
   if(SIZEOF_SIGNED_SHORT EQUAL 2)
 set(XERCES_S16BIT_INT "signed short")
-  elseif(SIZEOF_INT EQUAL 2)
+  elseif(SIZEOF_SIGNED_INT EQUAL 2)
 set(XERCES_S16BIT_INT "int")
   else()
 message(FATAL_ERROR "Couldn't find a signed 16-bit type")
@@ -132,12 +132,12 @@ else()
 message(FATAL_ERROR "Couldn't find an unsigned 32-bit type")
   endif()
 
-  if(SIZEOF_INT EQUAL 8)
-set(XERCES_S64BIT_INT "int")
-  elseif(SIZEOF_LONG EQUAL 8)
-set(XERCES_S64BIT_INT "long")
-  elseif(SIZEOF_LONG_LONG EQUAL 8)
-set(XERCES_S64BIT_INT "long long")
+  if(SIZEOF_SIGNED_INT EQUAL 8)
+set(XERCES_S64BIT_INT "signed int")
+  elseif(SIZEOF_SIGNED_LONG EQUAL 8)
+set(XERCES_S64BIT_INT "signed long")
+  elseif(SIZEOF_SIGNED_LONG_LONG EQUAL 8)
+set(XERCES_S64BIT_INT "signed long long")
   elseif(SIZEOF___INT64 EQUAL 8)
 set(XERCES_S64BIT_INT "__int64")
   else()
-- 
2.13.1



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

Re: Integrating CMake support for xerces

[Vitaly Prapirny]

Roger Leigh wrote on 21/06/2017 12:20:

On 21/06/17 08:48, Vitaly Prapirny wrote:
I've got an error while running cmake with "Borland Makefiles" 
generator and Borland C++ Builder 5 compiler. Is BCB5 still supported?


It's not a combination I've personally tested, but I can't see any 
evidence that it shouldn't work.


What are the errors you are seeing?  Maybe it just needs a few minor 
tweaks to our cmake logic.
I've attached log files to the 
https://issues.apache.org/jira/browse/XERCESC-2077


Good luck!
   Vitaly

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

[jira] [Updated] (XERCESC-2077) Add CMake build system

[Vitaly Prapirny (JIRA)]

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

Vitaly Prapirny updated XERCESC-2077:
-
Attachment: cmake_bcb5_err.zip

CMake error with "Borland Makefiles" generator and Borland C++ Builder 5 
compiler.

> Add CMake build system
> --
>
> Key: XERCESC-2077
> URL: https://issues.apache.org/jira/browse/XERCESC-2077
> Project: Xerces-C++
>  Issue Type: New Feature
>  Components: Build
>Affects Versions: 3.1.4
> Environment: All
>Reporter: Roger Leigh
>  Labels: build, cmake, patch
> Fix For: 3.2.0
>
> Attachments: 0001-cmake-Add-CMake-build-system.patch, 
> 0001-cmake-Add-CMake-build-system-trunk.patch, 
> 0002-cmake-Align-versioning-with-Autotools-and-Visual-Stu.patch, 
> cmake_bcb5_err.zip, screenshot-xerces-ci-tests-trunk.png
>
>
> h4. Introduction
> The attached patch implements a CMake build for Xerces-C++.
> I have spent significant effort performing a "comprehensive" conversion of 
> the existing GNU autotools and MSVC project file logic to a unified CMake 
> build which supports all platforms with a single set of build files, as well 
> as testing it exhaustively (see below). The existing GNU autotools build and 
> MSVC project builds will continue to function and are unaffected by this 
> addition.
> h5. References
> - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201302.mbox/browser
> - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201506.mbox/browser
> - https://github.com/rleigh-codelibre/xerces-c/tree/cmake-3.1
> h4. Background
> CMake is a meta-build system which generates the build files for a specified 
> build system, such as make, Visual Studio msbuild, nmake, ninja or a number 
> of other build tools and IDEs.  This allows Xerces-C++ to be built on any 
> supported platform with the native tools for that platform.
> The reason why I originally needed this was due to the large maintenance 
> burden of patching the provided Visual Studio project files, both for fixing 
> bugs in those files and in being able to support versions of Visual Studio 
> which aren't yet supported by the provided project files or for unsupported 
> configurations e.g. Clang/C2, other platforms etc.  The lack of an install 
> target also meant that to integrate this with a larger build required 
> manually copying bits out of the build tree.  The cost of debugging and 
> patching the existing project files for use in our CI builds was getting too 
> great--maintaining and using this CMake build out of tree will be cheaper and 
> more robust.  However, given that other people have also requested such 
> support in the past, I thought it might benefit others to have this merged 
> upstream so that it would be available to the benefit of all.
> I have done a direct conversion of every autoconf option and feature test.  
> Where there wasn't a direct CMake equivalent, I've written each feature test 
> to exactly match the autoconf behaviour.  The automake Makefile.am logic is 
> directly represented in the corresponding CMakeLists.txt files.  Broadly:
> ||Autotools||CMake||
> |{{configure.ac}}, {{Makefile.am}}|{{CMakeLists.txt}}|
> |{{*/Makefile.am}}|{{*/CMakeLists.txt}}|
> |{{m4/*}}|{{cmake/*}}|
> |{{src/xercesc/util/Xerces_autoconf_config.hpp.in}}|{{src/xercesc/util/Xerces_autoconf_config.hpp.cmake.in}}|
> |_autoheader_|config.h.cmake.in|
> |{{tools/createdocs.sh}}|{{CMakeLists.txt}} (custom target)|
> |{{scripts/sanityTest.pl}}|{{cmake/XercesTest.cmake}} (direct support)|
> |{{scripts/sanityTest_ExpectedResult.log}}|{{test/expected/\*}}, 
> {{samples/expected/\*}} (individual log files)|
> And there's a section added to the documentation giving an overview of how to 
> use it, in the same style as the autotools section.
> h5. Enhancements over the existing build systems
> - Universal build for any platform and build system supported by CMake
> - Full support for feature and library detection on Windows, including
>   discovery of ICU libraries; it's no longer static, using (long broken)
>   ICU configurations in the project files
> - An install target now exists on Windows, so the various pieces don't
>   need manually copying out of the build tree
> - Parallel build speed improvements when using ninja to replace make
>   or msbuild; the speedup with the latter is significant
> - Export of CMake configuration in addition to pkg-config, to make
>   Xerces-C++ integrate with downstream projects using Xerces-C++ and
>   cmake; this includes all dependency information of the libraries
>   Xerces was linked with, i.e. transitive dependencies.
> - Installs the HTML documentation
> - Targets are provided for regenerating the documentation (docs and
>   apidocs)
> - Documentation can be edited and rebuilt from within Visual Studio
> - Unit tests can be run 

Re: Integrating CMake support for xerces

[Roger Leigh]

On 21/06/17 08:48, Vitaly Prapirny wrote:

Roger Leigh wrote on 21/06/2017 09:54:

On 21/06/17 02:42, Cantor, Scott wrote:
Are the Xerces_autoconf_config.borland.hpp and 
Xerces_autoconf_config.msvc.hpp files "pre-cmake"? IIRC, I think 
those are the hardwired versions used in the old builds.


I don't want to leave them on trunk if they're going to atrophy and I 
don't really imagine we'd be doing anything to ensure they worked if 
the solution files came from cmake now.


Yes, these are only used by the old project files. CMake ignores them 
entirely, so they can certainly be removed.
I've got an error while running cmake with "Borland Makefiles" generator 
and Borland C++ Builder 5 compiler. Is BCB5 still supported?


It's not a combination I've personally tested, but I can't see any 
evidence that it shouldn't work.


What are the errors you are seeing?  Maybe it just needs a few minor 
tweaks to our cmake logic.



Regards,
Roger

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

Re: Integrating CMake support for xerces

[Vitaly Prapirny]

Roger Leigh wrote on 21/06/2017 09:54:

On 21/06/17 02:42, Cantor, Scott wrote:
Are the Xerces_autoconf_config.borland.hpp and 
Xerces_autoconf_config.msvc.hpp files "pre-cmake"? IIRC, I think 
those are the hardwired versions used in the old builds.


I don't want to leave them on trunk if they're going to atrophy and I 
don't really imagine we'd be doing anything to ensure they worked if 
the solution files came from cmake now.


Yes, these are only used by the old project files. CMake ignores them 
entirely, so they can certainly be removed.
I've got an error while running cmake with "Borland Makefiles" generator 
and Borland C++ Builder 5 compiler. Is BCB5 still supported?


Good luck!
   Vitaly


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

[jira] [Commented] (XERCESC-2102) Documentation is not generatable on modern systems

[Roger Leigh (JIRA)]

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

Roger Leigh commented on XERCESC-2102:
--

I can certainly run Java 1.6 in an old virtual machine if need be.

Regarding wikis, how about conversion to markdown?  It's supported by several 
wikis, but it also has the nice properly of being supported by GitHub, GitLab 
and others, so you can directly browse the documentation in the repo and have 
it nicely rendered.  It would keep the maintenance burden low, and it's pretty 
accessible for anyone who wanted to work on any docs changes.

> Documentation is not generatable on modern systems
> --
>
> Key: XERCESC-2102
> URL: https://issues.apache.org/jira/browse/XERCESC-2102
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Roger Leigh
>
> The "stylebook" documentation format relies upon {{stylebook-1.0-b2.jar}}.  
> Unfortunately this tool appears to no longer be developed and it no longer 
> works with contemporary JREs due to relying upon 
> {com.sun.image.codec.jpeg.JPEGCodec} which is no longer present.  It's 
> achievable by trying to find a Java 1.6 or earlier JRE, but this is becoming 
> increasingly difficult to make work.
> Was there ever a migration path from slidebook to any other format which is 
> currently supported?
> Would there be any interest in moving to a contemporary documentation format, 
> and if so are there any preferred formats?  At work we use Sphinx.  I'd be 
> happy to spend a few hours converting it to this or some other format which 
> is currently supported.
> Regards,
> Roger
> {noformat}
> % make createdocs   
> [StyleBook] Overriding 
> targetDirectory="/home/rleigh/code/xerces-svn-trunk/doc/html" (Old=".")
> [StyleBook] Project URL: "sbk:/sources/xerces-c_book.xml"
> [BasicEngine] Initializing
> [Loader] Parsing Project file
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/book2project.xsl"
> [XalanProcessor] Applying XSL sheet 
> "sbk:/style/stylesheets/directory2project.xsl"
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (1)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (2)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (3)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (4)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (5)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (6)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (7)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (8)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (9)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (10)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (11)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (12)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (13)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (14)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (15)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document 
> "sbk:/style/stylesheets/any2project.xsl" (16)
> [XalanProcessor] Applying 

Re: Integrating CMake support for xerces

[Roger Leigh]

On 21/06/17 02:42, Cantor, Scott wrote:

Are the Xerces_autoconf_config.borland.hpp and Xerces_autoconf_config.msvc.hpp files 
"pre-cmake"? IIRC, I think those are the hardwired versions used in the old 
builds.

I don't want to leave them on trunk if they're going to atrophy and I don't 
really imagine we'd be doing anything to ensure they worked if the solution 
files came from cmake now.


Yes, these are only used by the old project files. CMake ignores them 
entirely, so they can certainly be removed.



Regards,
Roger

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