[jira] Updated: (XERCESC-1910) The RegularExpression 'matches' function no longer returns the start and end position of a match
[
https://issues.apache.org/jira/browse/XERCESC-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov updated XERCESC-1910:
-
Fix Version/s: 3.1.0
(was: 3.2.0)
(was: 3.1.1)
The RegularExpression 'matches' function no longer returns the start and end
position of a match
Key: XERCESC-1910
URL: https://issues.apache.org/jira/browse/XERCESC-1910
Project: Xerces-C++
Issue Type: Bug
Components: Utilities
Affects Versions: 3.0.1
Environment: Windows
Reporter: Steve Roberts
Fix For: 3.1.0
We have recently upgraded from version 2.2.0 to version 3.0.1. Between these
versions a change was made to the RegularExpression::matchUnion function, so
that it now uses a local version of the context structure. The result of this
is that the 'fMatch' member of the context can be changed from its original
instance. Therefore, back in the RegularExpression::matches function, just
before it returns, it sets the start and end position of the match:
context.fMatch-setStartPos(0, (int)matchStart);
context.fMatch-setEndPos(0, matchEnd);
However, the 'fMatch' object no longer matches the one that was passed
through to function (due to what happened in 'matchUnion') and therefore
these values don't get returned to the calling function.
Therefore, I think that in the 'matches' function is should actually be
setting the start and end position of the 'pMatch' property that is passed
into the function, rather than the 'context.fMatch'.
The code we are using to call the regular expression is this:
XERCES_CPP_NAMESPACE::RegularExpression re(expression.c_str());
if( re.matches( text, match ) )
{ ...
where expression = ([\-\(]?\d{1,3}([,
]\d{3})+\.\d+[\)]?|[\-\(]?\d+\.\d+[\)]?).*
and text = 13.13
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1910) The RegularExpression 'matches' function no longer returns the start and end position of a match
[
https://issues.apache.org/jira/browse/XERCESC-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-1910.
Assuming this is fixed since 3.1.0.
The RegularExpression 'matches' function no longer returns the start and end
position of a match
Key: XERCESC-1910
URL: https://issues.apache.org/jira/browse/XERCESC-1910
Project: Xerces-C++
Issue Type: Bug
Components: Utilities
Affects Versions: 3.0.1
Environment: Windows
Reporter: Steve Roberts
Fix For: 3.1.0
We have recently upgraded from version 2.2.0 to version 3.0.1. Between these
versions a change was made to the RegularExpression::matchUnion function, so
that it now uses a local version of the context structure. The result of this
is that the 'fMatch' member of the context can be changed from its original
instance. Therefore, back in the RegularExpression::matches function, just
before it returns, it sets the start and end position of the match:
context.fMatch-setStartPos(0, (int)matchStart);
context.fMatch-setEndPos(0, matchEnd);
However, the 'fMatch' object no longer matches the one that was passed
through to function (due to what happened in 'matchUnion') and therefore
these values don't get returned to the calling function.
Therefore, I think that in the 'matches' function is should actually be
setting the start and end position of the 'pMatch' property that is passed
into the function, rather than the 'context.fMatch'.
The code we are using to call the regular expression is this:
XERCES_CPP_NAMESPACE::RegularExpression re(expression.c_str());
if( re.matches( text, match ) )
{ ...
where expression = ([\-\(]?\d{1,3}([,
]\d{3})+\.\d+[\)]?|[\-\(]?\d+\.\d+[\)]?).*
and text = 13.13
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (XERCESC-1914) SEnumVal does not produce correct output
[ https://issues.apache.org/jira/browse/XERCESC-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1914: - Fix Version/s: 3.1.1 3.2.0 Need to check what's going on here. SEnumVal does not produce correct output Key: XERCESC-1914 URL: https://issues.apache.org/jira/browse/XERCESC-1914 Project: Xerces-C++ Issue Type: Bug Components: Samples/Tests Affects Versions: 3.1.0 Environment: Windows Reporter: David Burrell Fix For: 3.1.1, 3.2.0 SEnumVal does not produce correct output. Our application relies on the ability to enumerate the grammar. The last release that worked correctly was 2.3.0. We cannot upgrade to any later version until we find a solution to this problem. The main problem is that the content model appears to be incorrect. This can be seen by comparing formatted content models produced by SEnumVal. Here is partial output from SEnumVal, comparing 2.3.0 with 3.1.0... xerces-c 2.3.0: (showing correct output) Name: category Model Type: Children Create Reason:Declared ContentType: OneOrMore Content Model:(severity)+ ComplexType: TypeName: ,C2 ContentType:OneOrMore Attributes: Name: name Type: CDATA Default Type: #REQUIRED Base Datatype: string Name: categoryCode Type: CDATA Default Type: #REQUIRED Base Datatype: string Enumeration: 0 1 2 3.1.0: ( incorrect - content model should be '(severity)+' ) Name: category Model Type: Children Create Reason:Declared ContentType: ModelGroupSequence Content Model:(severity,) ComplexType: TypeName: ,__AnonC2 ContentType:ModelGroupSequence Attributes: Name: categoryCode Type: CDATA Default Type: #REQUIRED Base Datatype: string Enumeration: 0 1 2 Name: name Type: CDATA Default Type: #REQUIRED Base Datatype: string -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (XERCESC-1785) Build and test on all supported platforms
[ https://issues.apache.org/jira/browse/XERCESC-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1785: - Fix Version/s: 3.2.0 (was: 3.1.0) Build and test on all supported platforms - Key: XERCESC-1785 URL: https://issues.apache.org/jira/browse/XERCESC-1785 Project: Xerces-C++ Issue Type: Task Components: Build Reporter: Boris Kolpackov Priority: Blocker Fix For: 3.2.0 We need to make sure that building, testing and installation work on all platforms that we have committed to support. See the following Wiki page for the status: http://wiki.apache.org/xerces/XercescBuildStatus -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Updated: (XERCESC-1907) PDB file name for static 64-bit debug builds in VC8 and VC9 project files are not library specific
[ https://issues.apache.org/jira/browse/XERCESC-1907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov updated XERCESC-1907: - Fix Version/s: 3.1.1 3.2.0 Scheduling for 3.1.1 PDB file name for static 64-bit debug builds in VC8 and VC9 project files are not library specific -- Key: XERCESC-1907 URL: https://issues.apache.org/jira/browse/XERCESC-1907 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 3.1.0 Environment: Windows Reporter: Boris Kolpackov Priority: Minor Fix For: 3.1.1, 3.2.0 The PDB file for static 64-bit debug builds in VC8 and VC9 project files are still names xerceslib_vc80.pdb. We have fixed this for 32-bit builds but not for 64-bit, for some reason. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1912) Conflicting includes cpuid.h and intrin.h (both define __cpuid)
[ https://issues.apache.org/jira/browse/XERCESC-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1912. Assignee: Boris Kolpackov Resolution: Fixed Fix is in SVN. Conflicting includes cpuid.h and intrin.h (both define __cpuid) --- Key: XERCESC-1912 URL: https://issues.apache.org/jira/browse/XERCESC-1912 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 3.1.0 Environment: GCC 4.4 (mingw) with mingw-w64 environment (64-bit, cross-compiling under Debian GNU/Linux) Reporter: Tommi Vainikainen Assignee: Boris Kolpackov Priority: Minor Fix For: 3.1.1, 3.2.0 GCC (since 4.3 AFAIK) contains cpuid.h which defines _get_cpuid(...) and __cpuid(level, a, b, c, d). intrin.h is Windows-API which defines __cpuid(int CPUInfo[4], int InfoType) Definitions of __cpuid are clearly not compatible. However when cross-compiling with GCC-mingw for Windows, configure script detects existence of both cpuid.h and intrin.h and includes both in PlatformUtils.cpp Following trivial patch workarounds this problem. diff -ur xerces-c-3.1.0/src/xercesc/util/PlatformUtils.cpp xerces-c-3.1.0.patched/src/xercesc/util/PlatformUtils.cpp --- xerces-c-3.1.0/src/xercesc/util/PlatformUtils.cpp 2009-08-28 16:21:24.0 +0300 +++ xerces-c-3.1.0.patched/src/xercesc/util/PlatformUtils.cpp 2010-02-15 11:16:33.0 +0200 @@ -37,7 +37,7 @@ #if HAVE_SYS_TIMEB_H #include sys/timeb.h #endif -#if HAVE_CPUID_H +#if HAVE_CPUID_H !XERCES_HAVE_INTRIN_H # include cpuid.h #endif -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1911) spelling fixes for xerces
[ https://issues.apache.org/jira/browse/XERCESC-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1911. Assignee: Boris Kolpackov Resolution: Fixed Changes are in SVN. Note also that there were a couple of wrong/incomplete fixes in the provided patch. spelling fixes for xerces - Key: XERCESC-1911 URL: https://issues.apache.org/jira/browse/XERCESC-1911 Project: Xerces-C++ Issue Type: Bug Reporter: timeless Assignee: Boris Kolpackov Priority: Trivial Fix For: 3.1.1, 3.2.0 Attachments: 12456044 I was running a spelling fix process against a Symbian repository and discovered that a portion of the changes was to Xerces, so I'm trying to deliver the spelling fixes here. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1907) PDB file name for static 64-bit debug builds in VC8 and VC9 project files are not library specific
[ https://issues.apache.org/jira/browse/XERCESC-1907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1907. Assignee: Boris Kolpackov Resolution: Fixed Fix is in SVN. PDB file name for static 64-bit debug builds in VC8 and VC9 project files are not library specific -- Key: XERCESC-1907 URL: https://issues.apache.org/jira/browse/XERCESC-1907 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 3.1.0 Environment: Windows Reporter: Boris Kolpackov Assignee: Boris Kolpackov Priority: Minor Fix For: 3.1.1, 3.2.0 The PDB file for static 64-bit debug builds in VC8 and VC9 project files are still names xerceslib_vc80.pdb. We have fixed this for 32-bit builds but not for 64-bit, for some reason. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Closed: (XERCESC-1918) XInclude broken with multiple level includes
[ https://issues.apache.org/jira/browse/XERCESC-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Kolpackov closed XERCESC-1918. Assignee: Boris Kolpackov Resolution: Fixed I have re-implemented the patch and committed it. Also fixed a few bugs and memory leaks in XInclude code while at it. XInclude broken with multiple level includes Key: XERCESC-1918 URL: https://issues.apache.org/jira/browse/XERCESC-1918 Project: Xerces-C++ Issue Type: Bug Components: Non-Validating Parser Affects Versions: 3.0.0 Environment: linux, windows Reporter: keith mcneill Assignee: Boris Kolpackov Fix For: 3.1.1, 3.2.0 Attachments: xerces-c-xinclude.diff, xinclude-bottom.xml, xinclude-middle.xml, xinclude-top.xml If you use xinclude on multiple levels ( 2) with relative path names. XInclude will break with an error something like no scheme. I tracked this down to a problem in XIncludeUtils::doDOMNodeXInclude. When an includeDoc was found it created a DocumentFragment to hang the new copied nodes off of. At the end of processing it would paste the DocumentFragment on to the document. The problem was that DocumentFragment lost the absolute path in its getBaseURI(). This absolute path also contained the scheme. This diff fixes XInclude by not using a DocumentFragment. We just use insertBefore() to insert the new nodes in the destination document in order. This way the getBaseURI() is never lost. I've also included a fix to XIncludeLocation.prependPath(). PrependPath used to slam a new path on the beginning of the current path without checking to see if the current path already had a scheme. For example you could end up with paths like: file:///new/parent/file:///old/child. Now it will produce file:///new/parent/old/child. XIncludeLocation probably needs to get smarter about dealing with schemes URI's in general. I've included a diff an example files that can be run with the XInclude sample. Note that with these fixes the xerces c++ xinclude behaves more like the java xinclude support. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
