date:20170712

[jira] [Resolved] (XERCESC-2054) Grammar serialization not portable (integer size / alignment issue)

2017-07-12 Thread Scott Cantor (JIRA)


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

Scott Cantor resolved XERCESC-2054.
---
Resolution: Duplicate

This was already reported, and there are some additional comments over in the 
original bug, so closing this.

> Grammar serialization not portable (integer size / alignment issue)
> ---
>
> Key: XERCESC-2054
> URL: https://issues.apache.org/jira/browse/XERCESC-2054
> Project: Xerces-C++
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.1.1, 3.1.2, 3.2.0, 3.1.3, 
> 3.1.4
> Environment: Linux CentOS-7 (64bit), Windows 7 (64bit)
>Reporter: Oliver Moeller
>
> Apologies if this is a known issue, but I have not found it by conventional
> means (i.e., google an searching through the bug data base here).
> I found that the serialisation/deserialisation (here: of grammars) is not as 
> portable as it (IMHO) should be.
> The problem happens in XSerializeEngine::readString() when
> the length of the string is taken from the associated BinInputStream as
> "unsigned long":
> /***
>  * Check if any data written
>  ***/
> unsigned long tmp;
> *this>>tmp;
> On a Windows7 x64, MSVS2012, this will take 4 byte off the head of the stream,
> but on a CentOS 7 x64 (g++ 4.8.3), this will take 8 byte.
> As a consequence, a BinInputStream carefully encoded on Windows (e.g. putting
> it into a char array with
>   examples/cxx/tree/embedded/grammar-input-stream.cxx
> which is a common xsd example)
> will fail when "reading" it on the Linux box, because everything from the 
> first
> string on is garbage.
> Moreover, this will (probably) give no meaningful error message, just a
> "XSerialisationException" thrown, cause at some point it will (probably)
> misinterpret wchar data as length information and try to read the next string
> that is millions of bytes long (according to the misunderstood 
> BinInputStream).
> The BinInputStream will then run out of bytes.
> A similar issue is present concerning the *alignment* of the data according 
> to data type that happens for all >> operations: this is (necessarily) very
> platform dependent.
> It would be a big improvement, if xerces would encode the (de)serialization
> in a platform/compiler independent manner. The purpose after all *IS* to be 
> portable, right?
> E.g., the serialisation engine could always use integers of known byte width
> (e.g.: #include  -> use uint32_t) instead of "unsigned long".
> ALso, the alignment issue should be addressed; it is hard to predict
> what restrictions apply for the used compiler (or even processor) here, some 
> are not capable to read an integer from a memory address that is not 4-byte 
> aligned.
> E.g., the data could be copied (to a properly aligned item initialized by 0s)
> before doing the cast to an integer type.
> In any case, it should always be platform-independent how many bytes are next 
> to be read from the BinaryInputStream.
> (Of course, the write operations have to follow the same business logic.)



--
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-1350) DTDElementDecl lazy initialization not thread safe.

2017-07-12 Thread Scott Cantor (JIRA)


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

Scott Cantor updated XERCESC-1350:
--
Affects Version/s: 3.2.0
   3.0.0
   3.1.0
   3.1.1
   3.1.2
   3.1.3
   3.1.4

> DTDElementDecl lazy initialization not thread safe.
> ---
>
> Key: XERCESC-1350
> URL: https://issues.apache.org/jira/browse/XERCESC-1350
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Validating Parser (DTD)
>Affects Versions: 3.0.0, 3.0.1, 3.1.0, 3.1.1, 3.1.2, 3.2.0, 3.1.3, 3.1.4
> Environment: Solaris
>Reporter: Mark Weissman
>
> DTDElementDecl.cpp && DTDElementDecl.hpp perform lazy evaluation on many
> of the get() methods.  This is used in cached grammars which may
> be shared by multiple threads and accessed unsynchonized.
> Lazy initialization is generally a bad pattern, but particularly in 
> multithreaded
> applications.  It should be disabled for shared grammars.  
> I work around this by calling all the getters when I create my Grammar pool
> but I think this should not be necessary.
> It would be good if somebody could check all the lazy evaluations that might
> affect shared grammars.



--
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-1600) make install for Windows

2017-07-12 Thread Scott Cantor (JIRA)


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

Scott Cantor updated XERCESC-1600:
--
Affects Version/s: (was: 2.7.0)

> make install for Windows
> 
>
> Key: XERCESC-1600
> URL: https://issues.apache.org/jira/browse/XERCESC-1600
> Project: Xerces-C++
>  Issue Type: New Feature
>  Components: Build
> Environment: Windows XP SP2
> Visual Studio .NET 2003 (Version 7.1.3088)
>Reporter: Giulio Troccoli
> Fix For: 3.2.0
>
>
> For our cross-platform application I had to build Xerces (and Xalan) on 
> Windows XP, AIX and Solaris. For the latter two the 'make install' command 
> copies not only the libraries but the include files (and some .c files too 
> which is correct). I find it very useful.
> Although it is easy to find and copy the *.dll and *.lib file in the right 
> place, copying the header file (and those .c files) is a big job and very 
> time consuming (I know, I could write a batch file) and very prone to missing 
> some files. It would be very helpful to provide an equivalent of 'make 
> istall' for Windows XP.



--
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-1600) make install for Windows

2017-07-12 Thread Scott Cantor (JIRA)


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

Scott Cantor resolved XERCESC-1600.
---
   Resolution: Fixed
Fix Version/s: 3.2.0

This is something the cmake build on the trunk can handle.

> make install for Windows
> 
>
> Key: XERCESC-1600
> URL: https://issues.apache.org/jira/browse/XERCESC-1600
> Project: Xerces-C++
>  Issue Type: New Feature
>  Components: Build
> Environment: Windows XP SP2
> Visual Studio .NET 2003 (Version 7.1.3088)
>Reporter: Giulio Troccoli
> Fix For: 3.2.0
>
>
> For our cross-platform application I had to build Xerces (and Xalan) on 
> Windows XP, AIX and Solaris. For the latter two the 'make install' command 
> copies not only the libraries but the include files (and some .c files too 
> which is correct). I find it very useful.
> Although it is easy to find and copy the *.dll and *.lib file in the right 
> place, copying the header file (and those .c files) is a big job and very 
> time consuming (I know, I could write a batch file) and very prone to missing 
> some files. It would be very helpful to provide an equivalent of 'make 
> istall' for Windows XP.



--
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-1959) serializeGrammars does not work between 32 and 64 bit systems

2017-07-12 Thread Scott Cantor (JIRA)


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

Scott Cantor updated XERCESC-1959:
--
Affects Version/s: 3.2.0
   3.0.0
   3.0.1
   3.1.0
   3.1.2
   3.1.3
   3.1.4

> serializeGrammars does not work between 32 and 64 bit systems
> -
>
> Key: XERCESC-1959
> URL: https://issues.apache.org/jira/browse/XERCESC-1959
> 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, 3.1.2, 3.2.0, 3.1.3, 3.1.4
> Environment: Win Vista 32 bit + VS 2010 express, Xerces-C 3.1.1 binary
> Ubuntu 10.10 64 bit, Xerces-C 3.1 installed
>Reporter: Daniel Turcanu
>
> Serialization of schema grammar does not work between Windows 32 and Linux 64 
> bit. Serializing on one machine (with serializeGrammars) and deserializing on 
> the other (with deserializeGrammars) fails ungracefully.
> Serializing and deserializing on the same machine works fine.



--
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] [Closed] (XERCESC-2054) Grammar serialization not portable (integer size / alignment issue)

2017-07-12 Thread Scott Cantor (JIRA)


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

Scott Cantor closed XERCESC-2054.
-

> Grammar serialization not portable (integer size / alignment issue)
> ---
>
> Key: XERCESC-2054
> URL: https://issues.apache.org/jira/browse/XERCESC-2054
> Project: Xerces-C++
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.1.1, 3.1.2, 3.2.0, 3.1.3, 
> 3.1.4
> Environment: Linux CentOS-7 (64bit), Windows 7 (64bit)
>Reporter: Oliver Moeller
>
> Apologies if this is a known issue, but I have not found it by conventional
> means (i.e., google an searching through the bug data base here).
> I found that the serialisation/deserialisation (here: of grammars) is not as 
> portable as it (IMHO) should be.
> The problem happens in XSerializeEngine::readString() when
> the length of the string is taken from the associated BinInputStream as
> "unsigned long":
> /***
>  * Check if any data written
>  ***/
> unsigned long tmp;
> *this>>tmp;
> On a Windows7 x64, MSVS2012, this will take 4 byte off the head of the stream,
> but on a CentOS 7 x64 (g++ 4.8.3), this will take 8 byte.
> As a consequence, a BinInputStream carefully encoded on Windows (e.g. putting
> it into a char array with
>   examples/cxx/tree/embedded/grammar-input-stream.cxx
> which is a common xsd example)
> will fail when "reading" it on the Linux box, because everything from the 
> first
> string on is garbage.
> Moreover, this will (probably) give no meaningful error message, just a
> "XSerialisationException" thrown, cause at some point it will (probably)
> misinterpret wchar data as length information and try to read the next string
> that is millions of bytes long (according to the misunderstood 
> BinInputStream).
> The BinInputStream will then run out of bytes.
> A similar issue is present concerning the *alignment* of the data according 
> to data type that happens for all >> operations: this is (necessarily) very
> platform dependent.
> It would be a big improvement, if xerces would encode the (de)serialization
> in a platform/compiler independent manner. The purpose after all *IS* to be 
> portable, right?
> E.g., the serialisation engine could always use integers of known byte width
> (e.g.: #include  -> use uint32_t) instead of "unsigned long".
> ALso, the alignment issue should be addressed; it is hard to predict
> what restrictions apply for the used compiler (or even processor) here, some 
> are not capable to read an integer from a memory address that is not 4-byte 
> aligned.
> E.g., the data could be copied (to a properly aligned item initialized by 0s)
> before doing the cast to an integer type.
> In any case, it should always be platform-independent how many bytes are next 
> to be read from the BinaryInputStream.
> (Of course, the write operations have to follow the same business logic.)



--
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] [Closed] (XERCESC-1954) Compilation errors in standard template library

2017-07-12 Thread Scott Cantor (JIRA)


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

Scott Cantor closed XERCESC-1954.
-

> Compilation errors in standard template library
> ---
>
> Key: XERCESC-1954
> URL: https://issues.apache.org/jira/browse/XERCESC-1954
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 2.8.0, 3.0.1
> Environment: WinXP, VC10.0
>Reporter: Rajesh G Manwani
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Compilation error for Project PSVIWriter : d:\vs2010\vc\include\fstream(222): 
> error C2146: syntax error : missing ';' before identifier 'overflow'



--
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-1954) Compilation errors in standard template library

2017-07-12 Thread Scott Cantor (JIRA)


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

Scott Cantor resolved XERCESC-1954.
---
Resolution: Invalid

> Compilation errors in standard template library
> ---
>
> Key: XERCESC-1954
> URL: https://issues.apache.org/jira/browse/XERCESC-1954
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 2.8.0, 3.0.1
> Environment: WinXP, VC10.0
>Reporter: Rajesh G Manwani
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Compilation error for Project PSVIWriter : d:\vs2010\vc\include\fstream(222): 
> error C2146: syntax error : missing ';' before identifier 'overflow'



--
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-1977) XMLUTF8Transcoder split surrogates causes Xalan to run out of memory

2017-07-12 Thread Scott Cantor (JIRA)


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

Scott Cantor commented on XERCESC-1977:
---

I'm not convinced this is a bug in Xerces, it seems like it's Xalan's bug. As 
long as the method returns what it consumed accurately, the caller should be 
required to compensate for that and re-submit the trailing byte.

I'm also not sure the XMLTranscoder contract is for non-thread-safety. This 
patch makes the object non-reentrant, so that definitely would need to be 
assessed for correctness. I don't see anything in the API doc for the interface 
indicating whether this is acceptable.

So given all that I'm not inclined to pull this in.

> XMLUTF8Transcoder split surrogates causes Xalan to run out of memory
> 
>
> Key: XERCESC-1977
> URL: https://issues.apache.org/jira/browse/XERCESC-1977
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 2.7.0
> Environment: Debian Linux 2.4.27
>Reporter: David K. Taylor
> Fix For: 2.7.0
>
> Attachments: xercesc-1977.patch
>
>
> When a surrogate pair is split at an input buffer boundary so only the high 
> surrogate is the last code point in the buffer when transcode() is called, 
> then XMLUTF8Transcoder succeeds but does not consume the entire buffer.  This 
> causes Xalan to loop infinitely, doubling the buffer each time, leading to an 
> out of memory failure.  The full backtrace is below.
> I will attach a patch that changes XMLUTF8Transcoder so that it saves the 
> dangling high surrogate in this case and uses it when transcode() is called 
> again.
> (gdb) Primary backtrace
> (gdb) =
> (gdb) #0  0xf6da37c7 in raise () from /lib/tls/libc.so.6
> #1  0xf6da4f49 in abort () from /lib/tls/libc.so.6
> #2  0xf6f4 in __gnu_cxx::__verbose_terminate_handler() () from
> /usr/lib/libstdc++.so.6
> #3  0xf6f973b5 in ?? () from /usr/lib/libstdc++.so.6
> #4  0xf6f973f2 in std::terminate() () from /usr/lib/libstdc++.so.6
> #5  0xf6f9752a in __cxa_throw () from /usr/lib/libstdc++.so.6
> #6  0xf76eee1d in xercesc_2_7::MemoryManagerImpl::allocate(unsigned int) ()
> from /usr/lib/libxerces-c.so.27
> #7  0xf724cd1a in xalanc_1_10::XalanOutputStream::transcode(unsigned short
> const*, unsigned int, xalanc_1_10::XalanVector xalanc_1_10::MemoryManagedConstructionTraits >&) () from
> /usr/lib/libxalan-c.so.110
> #8  0xf724d1af in xalanc_1_10::XalanOutputStream::doWrite(unsigned short
> const*, unsigned int) () from /usr/lib/libxalan-c.so.110
> #9  0xf724d213 in xalanc_1_10::XalanOutputStream::flushBuffer() () from
> /usr/lib/libxalan-c.so.110
> #10 0xf724eec8 in xalanc_1_10::XalanOutputStreamPrintWriter::write(unsigned
> short) () from /usr/lib/libxalan-c.so.110
> #11 0xf7268e6a in xalanc_1_10::FormatterToText::characters(unsigned short
> const*, unsigned int) () from /usr/lib/libxalan-c.so.110
> #12 0xf7418674 in xalanc_1_10::XSLTEngineImpl::characters(unsigned short
> const*, unsigned int, unsigned int) () from /usr/lib/libxalan-c.so.110
> #13 0xf73d0ce8 in
> xalanc_1_10::StylesheetExecutionContextDefault::characters(unsigned short
> const*, unsigned int, unsigned int) () from /usr/lib/libxalan-c.so.110
> #14 0xf737c5bb in xalanc_1_10::FormatterListenerAdapater::characters(unsigned
> short const*, unsigned int) () from /usr/lib/libxalan-c.so.110
> #15 0xf725484d in
> xalanc_1_10::DOMServices::getNodeData(xalanc_1_10::XalanElement const&,
> xalanc_1_10::FormatterListener&, void
> (xalanc_1_10::FormatterListener::*)(unsigned short const*, unsigned int)) ()
> from /usr/lib/libxalan-c.so.110
> #16 0xf7254b63 in xalanc_1_10::DOMServices::getNodeData(xalanc_1_10::XalanNode
> const&, xalanc_1_10::FormatterListener&, void
> (xalanc_1_10::FormatterListener::*)(unsigned short const*, unsigned int)) ()
> from /usr/lib/libxalan-c.so.110
> #17 0xf72a3947 in
> xalanc_1_10::XNodeSetBase::str(xalanc_1_10::FormatterListener&, void
> (xalanc_1_10::FormatterListener::*)(unsigned short const*, unsigned int)) 
> const
> () from /usr/lib/libxalan-c.so.110
> #18 0xf72be80e in xalanc_1_10::XPath::executeMore(xalanc_1_10::XalanNode*, int
> const*, xalanc_1_10::XPathExecutionContext&, xalanc_1_10::FormatterListener&,
> void (xalanc_1_10::FormatterListener::*)(unsigned short const*, unsigned int))
> const () from /usr/lib/libxalan-c.so.110
> #19 0xf737c377 in
> xalanc_1_10::ElemValueOf::startElement(xalanc_1_10::StylesheetExecutionContext&)
> const () from /usr/lib/libxalan-c.so.110
> #20 0xf73786ac in
> xalanc_1_10::ElemTemplateElement::execute(xalanc_1_10::StylesheetExecutionContext&)
> const () from /usr/lib/libxalan-c.so.110
> #21 0xf73f9f92 in 
> xalanc_1_10::StylesheetRoot::process(xalanc_1_10::XalanNode*,
>

[jira] [Closed] (XERCESC-1189) No indication of correct header file

2017-07-12 Thread Scott Cantor (JIRA)


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

Scott Cantor closed XERCESC-1189.
-

> No indication of correct header file
> 
>
> Key: XERCESC-1189
> URL: https://issues.apache.org/jira/browse/XERCESC-1189
> Project: Xerces-C++
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: 2.5.0
> Environment: Operating System: Other
> Platform: Other
>Reporter: Jerry Quinn
>
> The documentation for XMLPlatformUtils should say what header file a program
> must include to get access to this class.  Especially as it's required to make
> any xerces program work.



--
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-1189) No indication of correct header file

2017-07-12 Thread Scott Cantor (JIRA)


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

Scott Cantor updated XERCESC-1189:
--
Issue Type: Improvement  (was: Bug)

> No indication of correct header file
> 
>
> Key: XERCESC-1189
> URL: https://issues.apache.org/jira/browse/XERCESC-1189
> Project: Xerces-C++
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: 2.5.0
> Environment: Operating System: Other
> Platform: Other
>Reporter: Jerry Quinn
>
> The documentation for XMLPlatformUtils should say what header file a program
> must include to get access to this class.  Especially as it's required to make
> any xerces program work.



--
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-1944) If an element is nil, child elements of this elements do not trigger a validation error

2017-07-12 Thread Scott Cantor (JIRA)


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

Scott Cantor updated XERCESC-1944:
--
Affects Version/s: 3.2.0
   3.0.0
   3.0.1
   3.1.1
   3.1.2
   3.1.3
   3.1.4

> If an element is nil, child elements of this elements do not trigger a 
> validation error
> ---
>
> Key: XERCESC-1944
> URL: https://issues.apache.org/jira/browse/XERCESC-1944
> 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, 3.1.2, 3.2.0, 3.1.3, 3.1.4
> Environment: Windows XP, Microsoft Visual C++ 2008
>Reporter: Andreas Awenius
> Fix For: 4.0.0
>
> Attachments: shiporder.xml, shiporder.xsd
>
>
> If an element is nil (xsi:nil="true") and this element has child elements, 
> Xercesc 3.1.0 does not report an error, although it should.
> According to this link:
> http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#cvc-elt
> an element that is nil may not have any content and any child elements.
> This behavior was also verified with Fujitsu's XWand XBRL Processor and 
> Altovas XMLSpy, which both issue this error.
> It seems as if Xercesc tries to implement this behavior, given that the 
> comments in SchemaValidator.cpp, line 129 are a direct copy of the mentioned 
> web page:
> // if nillable, it's an error to have value
> // XML Schema REC: Validation Rule: Element Locally Valid (Element)
> // 3.2.1 The element information item must have no
> // character or element information item [children].
> //
> However, no error is issued in such a constellation.
> There is a related issue:
> If the first child element of the nilled value (which is *not* nil) has 
> content, Xercesc issues the misguiding error message:
> Message: element '' is nil and must be empty
> It seems, as if the nil-flag of the parent element is incorrectly set for the 
> child element.
> For the second and all other child elements this is not the case (no error is 
> reported).
> Steps to reproduce:
> Use the attached schema and instance document.
> Invoke the DOMCount-sample from the Xercesc-distribution like this:
> DOMCount.exe -v=always -s -n -f shiporder.xml



--
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-1952) Different validation results for different empty element syntax: vs.

2017-07-12 Thread Scott Cantor (JIRA)


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

Scott Cantor updated XERCESC-1952:
--
Fix Version/s: 4.0.0

> Different validation results for different empty element syntax:  xsi:nil="true" /> vs. 
> 
>
> Key: XERCESC-1952
> URL: https://issues.apache.org/jira/browse/XERCESC-1952
> 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, 3.1.2, 3.2.0, 3.1.3, 3.1.4
> Environment: Windows Vista
>Reporter: Alexey Miroshnichenko
> Fix For: 4.0.0
>
> Attachments: note.xml, note.xsd, xerces-nillable2.patch, 
> xerces-nillable2.patch
>
>
> In case of   syntax for empty element used, XSD 
> validation reports follow message
>   Message: element 'subitem' is nil and must be empty
> In case empty element defined as  there is no validation 
> error.
> XML file:
> ===
> 
> http://www.test;
>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>   xsi:schemaLocation="http://www.test note.xsd">
> 
>   
>   text1
>   
>   text2
>   
> 
> 
> ===
> XSD file:
> ===
> 
> http://www.w3.org/2001/XMLSchema;
>   xmlns="http://www.test;
>   elementFormDefault="qualified"
>   targetNamespace="http://www.test;>
> 
> 
> 
> 
> 
> 
>  type="xs:anyType" minOccurs="0" />
> 
> 
> 
> 
> 
> 
> 
> ===



--
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-1189) No indication of correct header file

2017-07-12 Thread Scott Cantor (JIRA)


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

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

Not gonna happen, needless to say.

> No indication of correct header file
> 
>
> Key: XERCESC-1189
> URL: https://issues.apache.org/jira/browse/XERCESC-1189
> Project: Xerces-C++
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: 2.5.0
> Environment: Operating System: Other
> Platform: Other
>Reporter: Jerry Quinn
>
> The documentation for XMLPlatformUtils should say what header file a program
> must include to get access to this class.  Especially as it's required to make
> any xerces program work.



--
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-1944) If an element is nil, child elements of this elements do not trigger a validation error

2017-07-12 Thread Scott Cantor (JIRA)


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

Scott Cantor updated XERCESC-1944:
--
Fix Version/s: 4.0.0

> If an element is nil, child elements of this elements do not trigger a 
> validation error
> ---
>
> Key: XERCESC-1944
> URL: https://issues.apache.org/jira/browse/XERCESC-1944
> 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, 3.1.2, 3.2.0, 3.1.3, 3.1.4
> Environment: Windows XP, Microsoft Visual C++ 2008
>Reporter: Andreas Awenius
> Fix For: 4.0.0
>
> Attachments: shiporder.xml, shiporder.xsd
>
>
> If an element is nil (xsi:nil="true") and this element has child elements, 
> Xercesc 3.1.0 does not report an error, although it should.
> According to this link:
> http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#cvc-elt
> an element that is nil may not have any content and any child elements.
> This behavior was also verified with Fujitsu's XWand XBRL Processor and 
> Altovas XMLSpy, which both issue this error.
> It seems as if Xercesc tries to implement this behavior, given that the 
> comments in SchemaValidator.cpp, line 129 are a direct copy of the mentioned 
> web page:
> // if nillable, it's an error to have value
> // XML Schema REC: Validation Rule: Element Locally Valid (Element)
> // 3.2.1 The element information item must have no
> // character or element information item [children].
> //
> However, no error is issued in such a constellation.
> There is a related issue:
> If the first child element of the nilled value (which is *not* nil) has 
> content, Xercesc issues the misguiding error message:
> Message: element '' is nil and must be empty
> It seems, as if the nil-flag of the parent element is incorrectly set for the 
> child element.
> For the second and all other child elements this is not the case (no error is 
> reported).
> Steps to reproduce:
> Use the attached schema and instance document.
> Invoke the DOMCount-sample from the Xercesc-distribution like this:
> DOMCount.exe -v=always -s -n -f shiporder.xml



--
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-1944) If an element is nil, child elements of this elements do not trigger a validation error

2017-07-12 Thread Scott Cantor (JIRA)


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

Scott Cantor commented on XERCESC-1944:
---

Patched proposed in linked issue but would involve an API change.

> If an element is nil, child elements of this elements do not trigger a 
> validation error
> ---
>
> Key: XERCESC-1944
> URL: https://issues.apache.org/jira/browse/XERCESC-1944
> 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, 3.1.2, 3.2.0, 3.1.3, 3.1.4
> Environment: Windows XP, Microsoft Visual C++ 2008
>Reporter: Andreas Awenius
> Fix For: 4.0.0
>
> Attachments: shiporder.xml, shiporder.xsd
>
>
> If an element is nil (xsi:nil="true") and this element has child elements, 
> Xercesc 3.1.0 does not report an error, although it should.
> According to this link:
> http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#cvc-elt
> an element that is nil may not have any content and any child elements.
> This behavior was also verified with Fujitsu's XWand XBRL Processor and 
> Altovas XMLSpy, which both issue this error.
> It seems as if Xercesc tries to implement this behavior, given that the 
> comments in SchemaValidator.cpp, line 129 are a direct copy of the mentioned 
> web page:
> // if nillable, it's an error to have value
> // XML Schema REC: Validation Rule: Element Locally Valid (Element)
> // 3.2.1 The element information item must have no
> // character or element information item [children].
> //
> However, no error is issued in such a constellation.
> There is a related issue:
> If the first child element of the nilled value (which is *not* nil) has 
> content, Xercesc issues the misguiding error message:
> Message: element '' is nil and must be empty
> It seems, as if the nil-flag of the parent element is incorrectly set for the 
> child element.
> For the second and all other child elements this is not the case (no error is 
> reported).
> Steps to reproduce:
> Use the attached schema and instance document.
> Invoke the DOMCount-sample from the Xercesc-distribution like this:
> DOMCount.exe -v=always -s -n -f shiporder.xml



--
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-1952) Different validation results for different empty element syntax: vs.

2017-07-12 Thread Scott Cantor (JIRA)


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

Scott Cantor commented on XERCESC-1952:
---

Proposed fix would be an API change, so scheduling it to 4.0.

> Different validation results for different empty element syntax:  xsi:nil="true" /> vs. 
> 
>
> Key: XERCESC-1952
> URL: https://issues.apache.org/jira/browse/XERCESC-1952
> 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, 3.1.2, 3.2.0, 3.1.3, 3.1.4
> Environment: Windows Vista
>Reporter: Alexey Miroshnichenko
> Fix For: 4.0.0
>
> Attachments: note.xml, note.xsd, xerces-nillable2.patch, 
> xerces-nillable2.patch
>
>
> In case of   syntax for empty element used, XSD 
> validation reports follow message
>   Message: element 'subitem' is nil and must be empty
> In case empty element defined as  there is no validation 
> error.
> XML file:
> ===
> 
> http://www.test;
>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>   xsi:schemaLocation="http://www.test note.xsd">
> 
>   
>   text1
>   
>   text2
>   
> 
> 
> ===
> XSD file:
> ===
> 
> http://www.w3.org/2001/XMLSchema;
>   xmlns="http://www.test;
>   elementFormDefault="qualified"
>   targetNamespace="http://www.test;>
> 
> 
> 
> 
> 
> 
>  type="xs:anyType" minOccurs="0" />
> 
> 
> 
> 
> 
> 
> 
> ===



--
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-1952) Different validation results for different empty element syntax: vs.

2017-07-12 Thread Scott Cantor (JIRA)


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

Scott Cantor updated XERCESC-1952:
--
Affects Version/s: 3.2.0
   3.0.0
   3.0.1
   3.1.0
   3.1.2
   3.1.3
   3.1.4

> Different validation results for different empty element syntax:  xsi:nil="true" /> vs. 
> 
>
> Key: XERCESC-1952
> URL: https://issues.apache.org/jira/browse/XERCESC-1952
> 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, 3.1.2, 3.2.0, 3.1.3, 3.1.4
> Environment: Windows Vista
>Reporter: Alexey Miroshnichenko
> Fix For: 4.0.0
>
> Attachments: note.xml, note.xsd, xerces-nillable2.patch, 
> xerces-nillable2.patch
>
>
> In case of   syntax for empty element used, XSD 
> validation reports follow message
>   Message: element 'subitem' is nil and must be empty
> In case empty element defined as  there is no validation 
> error.
> XML file:
> ===
> 
> http://www.test;
>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>   xsi:schemaLocation="http://www.test note.xsd">
> 
>   
>   text1
>   
>   text2
>   
> 
> 
> ===
> XSD file:
> ===
> 
> http://www.w3.org/2001/XMLSchema;
>   xmlns="http://www.test;
>   elementFormDefault="qualified"
>   targetNamespace="http://www.test;>
> 
> 
> 
> 
> 
> 
>  type="xs:anyType" minOccurs="0" />
> 
> 
> 
> 
> 
> 
> 
> ===



--
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-2054) Grammar serialization not portable (integer size / alignment issue)

2017-07-12 Thread Scott Cantor (JIRA)


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

Scott Cantor updated XERCESC-2054:
--
Affects Version/s: 3.2.0
   3.0.0
   3.0.1
   3.1.3
   3.1.4

> Grammar serialization not portable (integer size / alignment issue)
> ---
>
> Key: XERCESC-2054
> URL: https://issues.apache.org/jira/browse/XERCESC-2054
> Project: Xerces-C++
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.1.1, 3.1.2, 3.2.0, 3.1.3, 
> 3.1.4
> Environment: Linux CentOS-7 (64bit), Windows 7 (64bit)
>Reporter: Oliver Moeller
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> Apologies if this is a known issue, but I have not found it by conventional
> means (i.e., google an searching through the bug data base here).
> I found that the serialisation/deserialisation (here: of grammars) is not as 
> portable as it (IMHO) should be.
> The problem happens in XSerializeEngine::readString() when
> the length of the string is taken from the associated BinInputStream as
> "unsigned long":
> /***
>  * Check if any data written
>  ***/
> unsigned long tmp;
> *this>>tmp;
> On a Windows7 x64, MSVS2012, this will take 4 byte off the head of the stream,
> but on a CentOS 7 x64 (g++ 4.8.3), this will take 8 byte.
> As a consequence, a BinInputStream carefully encoded on Windows (e.g. putting
> it into a char array with
>   examples/cxx/tree/embedded/grammar-input-stream.cxx
> which is a common xsd example)
> will fail when "reading" it on the Linux box, because everything from the 
> first
> string on is garbage.
> Moreover, this will (probably) give no meaningful error message, just a
> "XSerialisationException" thrown, cause at some point it will (probably)
> misinterpret wchar data as length information and try to read the next string
> that is millions of bytes long (according to the misunderstood 
> BinInputStream).
> The BinInputStream will then run out of bytes.
> A similar issue is present concerning the *alignment* of the data according 
> to data type that happens for all >> operations: this is (necessarily) very
> platform dependent.
> It would be a big improvement, if xerces would encode the (de)serialization
> in a platform/compiler independent manner. The purpose after all *IS* to be 
> portable, right?
> E.g., the serialisation engine could always use integers of known byte width
> (e.g.: #include  -> use uint32_t) instead of "unsigned long".
> ALso, the alignment issue should be addressed; it is hard to predict
> what restrictions apply for the used compiler (or even processor) here, some 
> are not capable to read an integer from a memory address that is not 4-byte 
> aligned.
> E.g., the data could be copied (to a properly aligned item initialized by 0s)
> before doing the cast to an integer type.
> In any case, it should always be platform-independent how many bytes are next 
> to be read from the BinaryInputStream.
> (Of course, the write operations have to follow the same business logic.)



--
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-2058) Alternative to getSingleNodeValue() method in libxerces 3.1

2017-07-12 Thread Scott Cantor (JIRA)


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

Scott Cantor resolved XERCESC-2058.
---
Resolution: Not A Bug

Please take questions to the mailing lists, not Jira. I do see the API changed, 
but I have no information on why, or anything else related to the change.

> Alternative to getSingleNodeValue() method in libxerces 3.1
> ---
>
> Key: XERCESC-2058
> URL: https://issues.apache.org/jira/browse/XERCESC-2058
> Project: Xerces-C++
>  Issue Type: Improvement
>  Components: DOM
>Affects Versions: 3.1.0
> Environment: Linux SLES
>Reporter: sowjanya 
>
> We are referring to  getSingleNodeValue() method present in 
> DOMXPathResult.hpp file in our project. But in version libxerces 3.1 version, 
> getSingleNodeValue() was not present in DOMXPathResult.hpp file.
> Could you please let us know if this method has been replaced with any other 
> method or alternative way to achieve this.



--
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] [Closed] (XERCESC-2055) DOMUserDataHandler not called when a removed node is deleted

2017-07-12 Thread Scott Cantor (JIRA)


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

Scott Cantor closed XERCESC-2055.
-

> DOMUserDataHandler not called when a removed node is deleted
> 
>
> Key: XERCESC-2055
> URL: https://issues.apache.org/jira/browse/XERCESC-2055
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: DOM
>Affects Versions: 3.1.0, 3.1.1, 3.1.2, 3.1.3, 3.1.4
> Environment: Windows 7
>Reporter: TRIPOZ Jacques
>
> The DOMUserDataHandler callback is not called if the node is removed (using 
> something like aNode->getParentNode()->removeChild(aNode);)
> I can send sample code demonstrating this.



--
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-2055) DOMUserDataHandler not called when a removed node is deleted

2017-07-12 Thread Scott Cantor (JIRA)


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

Scott Cantor updated XERCESC-2055:
--
Affects Version/s: 3.1.0
   3.1.2
   3.1.3
   3.1.4

> DOMUserDataHandler not called when a removed node is deleted
> 
>
> Key: XERCESC-2055
> URL: https://issues.apache.org/jira/browse/XERCESC-2055
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: DOM
>Affects Versions: 3.1.0, 3.1.1, 3.1.2, 3.1.3, 3.1.4
> Environment: Windows 7
>Reporter: TRIPOZ Jacques
>
> The DOMUserDataHandler callback is not called if the node is removed (using 
> something like aNode->getParentNode()->removeChild(aNode);)
> I can send sample code demonstrating this.



--
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-2055) DOMUserDataHandler not called when a removed node is deleted

2017-07-12 Thread Scott Cantor (JIRA)


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

Scott Cantor resolved XERCESC-2055.
---
Resolution: Not A Problem

If you can find a reference showing otherwise, please add it, but my quick read 
is that there is no reason it should be. NODE_DELETED gets called on release, 
but removing a child doesn't release it, just removes it from the tree. There's 
no NODE_REMOVED or NODE_ORPHANED event.

> DOMUserDataHandler not called when a removed node is deleted
> 
>
> Key: XERCESC-2055
> URL: https://issues.apache.org/jira/browse/XERCESC-2055
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: DOM
>Affects Versions: 3.1.0, 3.1.1, 3.1.2, 3.1.3, 3.1.4
> Environment: Windows 7
>Reporter: TRIPOZ Jacques
>
> The DOMUserDataHandler callback is not called if the node is removed (using 
> something like aNode->getParentNode()->removeChild(aNode);)
> I can send sample code demonstrating this.



--
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-2054) Grammar serialization not portable (integer size / alignment issue)

2017-07-12 Thread Scott Cantor (JIRA)


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

Scott Cantor commented on XERCESC-2054:
---

(The implied point being, if this is some weird atypical feature it should get 
yanked if there's ever a 4.0.)

> Grammar serialization not portable (integer size / alignment issue)
> ---
>
> Key: XERCESC-2054
> URL: https://issues.apache.org/jira/browse/XERCESC-2054
> Project: Xerces-C++
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.1.1, 3.1.2, 3.2.0, 3.1.3, 
> 3.1.4
> Environment: Linux CentOS-7 (64bit), Windows 7 (64bit)
>Reporter: Oliver Moeller
>
> Apologies if this is a known issue, but I have not found it by conventional
> means (i.e., google an searching through the bug data base here).
> I found that the serialisation/deserialisation (here: of grammars) is not as 
> portable as it (IMHO) should be.
> The problem happens in XSerializeEngine::readString() when
> the length of the string is taken from the associated BinInputStream as
> "unsigned long":
> /***
>  * Check if any data written
>  ***/
> unsigned long tmp;
> *this>>tmp;
> On a Windows7 x64, MSVS2012, this will take 4 byte off the head of the stream,
> but on a CentOS 7 x64 (g++ 4.8.3), this will take 8 byte.
> As a consequence, a BinInputStream carefully encoded on Windows (e.g. putting
> it into a char array with
>   examples/cxx/tree/embedded/grammar-input-stream.cxx
> which is a common xsd example)
> will fail when "reading" it on the Linux box, because everything from the 
> first
> string on is garbage.
> Moreover, this will (probably) give no meaningful error message, just a
> "XSerialisationException" thrown, cause at some point it will (probably)
> misinterpret wchar data as length information and try to read the next string
> that is millions of bytes long (according to the misunderstood 
> BinInputStream).
> The BinInputStream will then run out of bytes.
> A similar issue is present concerning the *alignment* of the data according 
> to data type that happens for all >> operations: this is (necessarily) very
> platform dependent.
> It would be a big improvement, if xerces would encode the (de)serialization
> in a platform/compiler independent manner. The purpose after all *IS* to be 
> portable, right?
> E.g., the serialisation engine could always use integers of known byte width
> (e.g.: #include  -> use uint32_t) instead of "unsigned long".
> ALso, the alignment issue should be addressed; it is hard to predict
> what restrictions apply for the used compiler (or even processor) here, some 
> are not capable to read an integer from a memory address that is not 4-byte 
> aligned.
> E.g., the data could be copied (to a properly aligned item initialized by 0s)
> before doing the cast to an integer type.
> In any case, it should always be platform-independent how many bytes are next 
> to be read from the BinaryInputStream.
> (Of course, the write operations have to follow the same business logic.)



--
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-2054) Grammar serialization not portable (integer size / alignment issue)

2017-07-12 Thread Scott Cantor (JIRA)


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

Scott Cantor updated XERCESC-2054:
--
Remaining Estimate: (was: 4h)
 Original Estimate: (was: 4h)

> Grammar serialization not portable (integer size / alignment issue)
> ---
>
> Key: XERCESC-2054
> URL: https://issues.apache.org/jira/browse/XERCESC-2054
> Project: Xerces-C++
>  Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.1.1, 3.1.2, 3.2.0, 3.1.3, 
> 3.1.4
> Environment: Linux CentOS-7 (64bit), Windows 7 (64bit)
>Reporter: Oliver Moeller
>
> Apologies if this is a known issue, but I have not found it by conventional
> means (i.e., google an searching through the bug data base here).
> I found that the serialisation/deserialisation (here: of grammars) is not as 
> portable as it (IMHO) should be.
> The problem happens in XSerializeEngine::readString() when
> the length of the string is taken from the associated BinInputStream as
> "unsigned long":
> /***
>  * Check if any data written
>  ***/
> unsigned long tmp;
> *this>>tmp;
> On a Windows7 x64, MSVS2012, this will take 4 byte off the head of the stream,
> but on a CentOS 7 x64 (g++ 4.8.3), this will take 8 byte.
> As a consequence, a BinInputStream carefully encoded on Windows (e.g. putting
> it into a char array with
>   examples/cxx/tree/embedded/grammar-input-stream.cxx
> which is a common xsd example)
> will fail when "reading" it on the Linux box, because everything from the 
> first
> string on is garbage.
> Moreover, this will (probably) give no meaningful error message, just a
> "XSerialisationException" thrown, cause at some point it will (probably)
> misinterpret wchar data as length information and try to read the next string
> that is millions of bytes long (according to the misunderstood 
> BinInputStream).
> The BinInputStream will then run out of bytes.
> A similar issue is present concerning the *alignment* of the data according 
> to data type that happens for all >> operations: this is (necessarily) very
> platform dependent.
> It would be a big improvement, if xerces would encode the (de)serialization
> in a platform/compiler independent manner. The purpose after all *IS* to be 
> portable, right?
> E.g., the serialisation engine could always use integers of known byte width
> (e.g.: #include  -> use uint32_t) instead of "unsigned long".
> ALso, the alignment issue should be addressed; it is hard to predict
> what restrictions apply for the used compiler (or even processor) here, some 
> are not capable to read an integer from a memory address that is not 4-byte 
> aligned.
> E.g., the data could be copied (to a properly aligned item initialized by 0s)
> before doing the cast to an integer type.
> In any case, it should always be platform-independent how many bytes are next 
> to be read from the BinaryInputStream.
> (Of course, the write operations have to follow the same business logic.)



--
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-2063) A 4 byte UTF-8 character incorrectly failing maxlenght facet.

2017-07-12 Thread Scott Cantor (JIRA)


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

Scott Cantor updated XERCESC-2063:
--
Affects Version/s: 3.0.0
   3.0.1
   3.1.0
   3.1.1
   3.1.2
   3.1.4

> A 4 byte UTF-8 character incorrectly failing maxlenght facet.
> -
>
> Key: XERCESC-2063
> URL: https://issues.apache.org/jira/browse/XERCESC-2063
> 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, 3.1.2, 3.2.0, 3.1.3, 3.1.4
> Environment: Windows (Affects all OS)
>Reporter: Greg Iwinski
>
> A 4 byte UTF-8 character incorrectly failing maxlenght facet.
> The data is F0 9D 90 80 and is a 4-byte UTF-8 sequence to represent 1 
> character.
> It is failing with
> Error at file input.xml, line 4, char 17
>   Message: value '??' has length '2' which exceeds maxLength facet value '1'
> when running  sax2count.exe
> This looks like a limitation but I could not find any documentation about it 
> in the bug list.
> **Input XML**
> 
> http://www.example.org/Test; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
> xsi:schemaLocation="http://www.example.org/Test
> Input.xsd">
>   퐀
> 
> **Schema**
> 
> http://www.example.org/Test; 
> elementFormDefault="qualified" xmlns="http://www.w3.org/2001/XMLSchema; 
> xmlns:tns="http://www.example.org/Test;>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 



--
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-2063) A 4 byte UTF-8 character incorrectly failing maxlenght facet.

2017-07-12 Thread Scott Cantor (JIRA)


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

Scott Cantor updated XERCESC-2063:
--
Affects Version/s: 3.2.0

> A 4 byte UTF-8 character incorrectly failing maxlenght facet.
> -
>
> Key: XERCESC-2063
> URL: https://issues.apache.org/jira/browse/XERCESC-2063
> 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, 3.1.2, 3.2.0, 3.1.3, 3.1.4
> Environment: Windows (Affects all OS)
>Reporter: Greg Iwinski
>
> A 4 byte UTF-8 character incorrectly failing maxlenght facet.
> The data is F0 9D 90 80 and is a 4-byte UTF-8 sequence to represent 1 
> character.
> It is failing with
> Error at file input.xml, line 4, char 17
>   Message: value '??' has length '2' which exceeds maxLength facet value '1'
> when running  sax2count.exe
> This looks like a limitation but I could not find any documentation about it 
> in the bug list.
> **Input XML**
> 
> http://www.example.org/Test; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
> xsi:schemaLocation="http://www.example.org/Test
> Input.xsd">
>   퐀
> 
> **Schema**
> 
> http://www.example.org/Test; 
> elementFormDefault="qualified" xmlns="http://www.w3.org/2001/XMLSchema; 
> xmlns:tns="http://www.example.org/Test;>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 



--
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-2063) A 4 byte UTF-8 character incorrectly failing maxlenght facet.

2017-07-12 Thread Scott Cantor (JIRA)


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

Scott Cantor commented on XERCESC-2063:
---

The limitation is due to the fact that it turns into a surrogate pair in 
UTF-16, so the string length in that encoding comes back as 2, much like a 
Unicode-ignorant strlen() against the original buffer would be 4.

> A 4 byte UTF-8 character incorrectly failing maxlenght facet.
> -
>
> Key: XERCESC-2063
> URL: https://issues.apache.org/jira/browse/XERCESC-2063
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Validating Parser (XML Schema)
>Affects Versions: 3.1.3
> Environment: Windows (Affects all OS)
>Reporter: Greg Iwinski
>
> A 4 byte UTF-8 character incorrectly failing maxlenght facet.
> The data is F0 9D 90 80 and is a 4-byte UTF-8 sequence to represent 1 
> character.
> It is failing with
> Error at file input.xml, line 4, char 17
>   Message: value '??' has length '2' which exceeds maxLength facet value '1'
> when running  sax2count.exe
> This looks like a limitation but I could not find any documentation about it 
> in the bug list.
> **Input XML**
> 
> http://www.example.org/Test; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
> xsi:schemaLocation="http://www.example.org/Test
> Input.xsd">
>   퐀
> 
> **Schema**
> 
> http://www.example.org/Test; 
> elementFormDefault="qualified" xmlns="http://www.w3.org/2001/XMLSchema; 
> xmlns:tns="http://www.example.org/Test;>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 



--
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] [Closed] (XERCESC-2074) [patch] Correct Win32 projects to link with the correct ICU libraries

2017-07-12 Thread Scott Cantor (JIRA)


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

Scott Cantor closed XERCESC-2074.
-

> [patch] Correct Win32 projects to link with the correct ICU libraries
> -
>
> Key: XERCESC-2074
> URL: https://issues.apache.org/jira/browse/XERCESC-2074
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 3.1.4
> Environment: Windows, using any of the VCnn projects with ICU 
> configurations
>Reporter: Roger Leigh
>  Labels: windows
> Attachments: 
> 0001-projects-Correct-ICU-libraries-to-link-for-each-conf.patch
>
>
> The various combinations of "ICU Release"|"ICU Debug" and Win32|x64 were 
> mostly incorrect, either using a release library where a debug library was 
> needed, or just plain not linking with any ICU library at all.
> The attached patch rectifies these problems for all VC versions.  It's been 
> specifically tested on our CI systems for VC12 and VC14, but the change is 
> identical for all older versions.



--
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-2074) [patch] Correct Win32 projects to link with the correct ICU libraries

2017-07-12 Thread Scott Cantor (JIRA)


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

Scott Cantor resolved XERCESC-2074.
---
Resolution: Won't Fix

Will be corrected with trunk release.

> [patch] Correct Win32 projects to link with the correct ICU libraries
> -
>
> Key: XERCESC-2074
> URL: https://issues.apache.org/jira/browse/XERCESC-2074
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 3.1.4
> Environment: Windows, using any of the VCnn projects with ICU 
> configurations
>Reporter: Roger Leigh
>  Labels: windows
> Attachments: 
> 0001-projects-Correct-ICU-libraries-to-link-for-each-conf.patch
>
>
> The various combinations of "ICU Release"|"ICU Debug" and Win32|x64 were 
> mostly incorrect, either using a release library where a debug library was 
> needed, or just plain not linking with any ICU library at all.
> The attached patch rectifies these problems for all VC versions.  It's been 
> specifically tested on our CI systems for VC12 and VC14, but the change is 
> identical for all older versions.



--
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] [Closed] (XERCESC-2076) Stray solution file added for VC14

2017-07-12 Thread Scott Cantor (JIRA)


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

Scott Cantor closed XERCESC-2076.
-

> Stray solution file added for VC14
> --
>
> Key: XERCESC-2076
> URL: https://issues.apache.org/jira/browse/XERCESC-2076
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 3.1.4
> Environment: N/A
>Reporter: Roger Leigh
>  Labels: vc14, windows
>
> % find projects -name '*.sln'
> projects/Win32/VC7.1/xerces-all/xerces-all.sln
> projects/Win32/VC9/xerces-all/xerces-all.sln
> projects/Win32/VC10/xerces-all/xerces-all.sln
> projects/Win32/VC14/xerces-all.sln
> projects/Win32/VC14/xerces-all/xerces-all.sln
> projects/Win32/VC11/xerces-all/xerces-all.sln
> projects/Win32/VC8/xerces-all/xerces-all.sln
> projects/Win32/VC12/xerces-all/xerces-all.sln
> projects/Win32/VC14/xerces-all.sln should not have been added; it can't be 
> used since all the paths are inaccessible.  Please could it be removed from 
> the source repository?



--
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-2076) Stray solution file added for VC14

2017-07-12 Thread Scott Cantor (JIRA)


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

Scott Cantor resolved XERCESC-2076.
---
Resolution: Won't Fix

We'll hit this when all the solutions are removed from trunk.

> Stray solution file added for VC14
> --
>
> Key: XERCESC-2076
> URL: https://issues.apache.org/jira/browse/XERCESC-2076
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 3.1.4
> Environment: N/A
>Reporter: Roger Leigh
>  Labels: vc14, windows
>
> % find projects -name '*.sln'
> projects/Win32/VC7.1/xerces-all/xerces-all.sln
> projects/Win32/VC9/xerces-all/xerces-all.sln
> projects/Win32/VC10/xerces-all/xerces-all.sln
> projects/Win32/VC14/xerces-all.sln
> projects/Win32/VC14/xerces-all/xerces-all.sln
> projects/Win32/VC11/xerces-all/xerces-all.sln
> projects/Win32/VC8/xerces-all/xerces-all.sln
> projects/Win32/VC12/xerces-all/xerces-all.sln
> projects/Win32/VC14/xerces-all.sln should not have been added; it can't be 
> used since all the paths are inaccessible.  Please could it be removed from 
> the source repository?



--
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-2071) Unable to transcode an UTF-8 multibyte string

2017-07-12 Thread Scott Cantor (JIRA)


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

Scott Cantor commented on XERCESC-2071:
---

Somebody would have to explain what the actual failure is here, and possibly 
attach a real sample that doesn't risk a cut and paste corruption.

Literally pasting that text into an XML file doesn't cause any issue. DOMPrint 
handles it, and a manual XMLString::transcode of the content doesn't fail, 
though I have no idea what the actual non-UTF8 output would even be meant to be.

I doubt I can fix it anyway, and wouldn't risk it, but if somebody understands 
this stuff and can provide a patch, great.

> Unable to transcode an UTF-8 multibyte string
> -
>
> Key: XERCESC-2071
> URL: https://issues.apache.org/jira/browse/XERCESC-2071
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 3.1.3
> Environment: Linux 32 bit, Armv6. Release version of the library
>Reporter: SandBeavers
>
> Xerces-C++ is unable to transcode a multiybyte UTF-8 string. For example 
> ❀★☀Happy❀★☀ throws an exception.



--
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-2101) Add support for XERCES_XMLCH_T = char16_t

2017-07-12 Thread Roger Leigh (JIRA)


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

Roger Leigh updated XERCESC-2101:
-
Attachment: (was: 0003-autoconf-Check-for-char16_t.patch)

> Add support for XERCES_XMLCH_T = char16_t
> -
>
> Key: XERCESC-2101
> URL: https://issues.apache.org/jira/browse/XERCESC-2101
> Project: Xerces-C++
>  Issue Type: Improvement
>Reporter: Vemund Handeland
>Assignee: Roger Leigh
>Priority: Minor
> Fix For: 3.2.0
>
> Attachments: char16_t.diff
>
>
> Attached diff contains the required changes for msvc. The diff is from my 
> local git repo created from the 3.1.4 release.
> Added new macro XERCES_USE_CHAR16_T.
> User can enable the support by define this macro both when building the 
> library and her own application.



--
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-2101) Add support for XERCES_XMLCH_T = char16_t

2017-07-12 Thread Roger Leigh (JIRA)


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

Roger Leigh updated XERCESC-2101:
-
Attachment: (was: 0002-cmake-Check-for-char16_t.patch)

> Add support for XERCES_XMLCH_T = char16_t
> -
>
> Key: XERCESC-2101
> URL: https://issues.apache.org/jira/browse/XERCESC-2101
> Project: Xerces-C++
>  Issue Type: Improvement
>Reporter: Vemund Handeland
>Assignee: Roger Leigh
>Priority: Minor
> Fix For: 3.2.0
>
> Attachments: char16_t.diff
>
>
> Attached diff contains the required changes for msvc. The diff is from my 
> local git repo created from the 3.1.4 release.
> Added new macro XERCES_USE_CHAR16_T.
> User can enable the support by define this macro both when building the 
> library and her own application.



--
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-2101) Add support for XERCES_XMLCH_T = char16_t

2017-07-12 Thread Roger Leigh (JIRA)


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

Roger Leigh updated XERCESC-2101:
-
Attachment: (was: 
0001-Add-Windows-support-for-XERCES_XMLCH_T-char16_t.patch)

> Add support for XERCES_XMLCH_T = char16_t
> -
>
> Key: XERCESC-2101
> URL: https://issues.apache.org/jira/browse/XERCESC-2101
> Project: Xerces-C++
>  Issue Type: Improvement
>Reporter: Vemund Handeland
>Assignee: Roger Leigh
>Priority: Minor
> Fix For: 3.2.0
>
> Attachments: char16_t.diff
>
>
> Attached diff contains the required changes for msvc. The diff is from my 
> local git repo created from the 3.1.4 release.
> Added new macro XERCES_USE_CHAR16_T.
> User can enable the support by define this macro both when building the 
> library and her own application.



--
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-2101) Add support for XERCES_XMLCH_T = char16_t

2017-07-12 Thread Roger Leigh (JIRA)


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

Roger Leigh updated XERCESC-2101:
-
Attachment: 0001-Add-Windows-support-for-XERCES_XMLCH_T-char16_t.patch
0002-cmake-Check-for-char16_t.patch
0003-autoconf-Check-for-char16_t.patch
0004-tests-Add-Char16Test.patch

Add unit test to demonstrate this works.

> Add support for XERCES_XMLCH_T = char16_t
> -
>
> Key: XERCESC-2101
> URL: https://issues.apache.org/jira/browse/XERCESC-2101
> Project: Xerces-C++
>  Issue Type: Improvement
>Reporter: Vemund Handeland
>Assignee: Roger Leigh
>Priority: Minor
> Fix For: 3.2.0
>
> Attachments: 
> 0001-Add-Windows-support-for-XERCES_XMLCH_T-char16_t.patch, 
> 0002-cmake-Check-for-char16_t.patch, 0003-autoconf-Check-for-char16_t.patch, 
> 0004-tests-Add-Char16Test.patch, char16_t.diff
>
>
> Attached diff contains the required changes for msvc. The diff is from my 
> local git repo created from the 3.1.4 release.
> Added new macro XERCES_USE_CHAR16_T.
> User can enable the support by define this macro both when building the 
> library and her own application.



--
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-2104) Add automake unit tests to match cmake tests

2017-07-12 Thread Roger Leigh (JIRA)


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

Roger Leigh resolved XERCESC-2104.
--
   Resolution: Fixed
 Assignee: Roger Leigh
Fix Version/s: 3.2.0

Fixed.  The automake and cmake unit tests now use the same test data.

> Add automake unit tests to match cmake tests
> 
>
> Key: XERCESC-2104
> URL: https://issues.apache.org/jira/browse/XERCESC-2104
> Project: Xerces-C++
>  Issue Type: Improvement
>  Components: Build
>Affects Versions: 3.2.0
>Reporter: Roger Leigh
>Assignee: Roger Leigh
>  Labels: automake, test-suite
> Fix For: 3.2.0
>
> Attachments: 
> 0001-cmake-Add-test-corrections-to-align-with-sanityTest-.patch, 
> 0002-Add-individual-automake-checks.patch, 
> 0003-automake-Use-silent-rules-in-place-of-custom-logic.patch
>
>
> The attached patches replace the sanityTest perl script with a set of small 
> scripts which allow the automake test-runner to run the unit tests 
> individually, as for cmake, including individual logs containing diffs where 
> there are errors.
> It also replaces some of the custom boilerplate in the Makefile.ams with 
> AM_SILENT_RULES, which does the same thing now it's directly supported in 
> automake (for a long time now, so all recent automake versions will support 
> it in practice).



--
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-2104) Add automake unit tests to match cmake tests

2017-07-12 Thread Roger Leigh (JIRA)


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

Roger Leigh commented on XERCESC-2104:
--

Committed to svn.  This makes the automake unit tests green again.

> Add automake unit tests to match cmake tests
> 
>
> Key: XERCESC-2104
> URL: https://issues.apache.org/jira/browse/XERCESC-2104
> Project: Xerces-C++
>  Issue Type: Improvement
>  Components: Build
>Affects Versions: 3.2.0
>Reporter: Roger Leigh
>  Labels: automake, test-suite
> Attachments: 
> 0001-cmake-Add-test-corrections-to-align-with-sanityTest-.patch, 
> 0002-Add-individual-automake-checks.patch, 
> 0003-automake-Use-silent-rules-in-place-of-custom-logic.patch
>
>
> The attached patches replace the sanityTest perl script with a set of small 
> scripts which allow the automake test-runner to run the unit tests 
> individually, as for cmake, including individual logs containing diffs where 
> there are errors.
> It also replaces some of the custom boilerplate in the Makefile.ams with 
> AM_SILENT_RULES, which does the same thing now it's directly supported in 
> automake (for a long time now, so all recent automake versions will support 
> it in practice).



--
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

39 matches

Mail list logo