[jira] [Assigned] (XERCESC-2163) XercesMessages_en_US.cat is installed to wrong directory
[
https://issues.apache.org/jira/browse/XERCESC-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roger Leigh reassigned XERCESC-2163:
Assignee: (was: Roger Leigh)
> XercesMessages_en_US.cat is installed to wrong directory
>
>
> Key: XERCESC-2163
> URL: https://issues.apache.org/jira/browse/XERCESC-2163
> Project: Xerces-C++
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.2.0, 3.2.1, 3.2.2, 3.2.3
>Reporter: Craig
>Priority: Major
> Labels: cmake
>
> When building with the
> {code}-Dmessage-loader=iconv{code}
> cmake option, {{XercesMessages_en_US.cat}} is installed to:
> {{/usr/msg/}}
> It should be installed to:
> {{/usr/share/xerces-c/msg/}}
> which is what previous versions of Xerces-C did.
> This change breaks downstream consumers of Xerces-C, such as Xalan-C (which
> fails to build as it cannot find {{XercesMessages_en_US.cat}}).
> Originally reported at https://bugs.gentoo.org/673548
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Assigned] (XERCESC-2135) build: GNU iconv transcoder only works on GNU/Linux
[ https://issues.apache.org/jira/browse/XERCESC-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh reassigned XERCESC-2135: Assignee: (was: Roger Leigh) > build: GNU iconv transcoder only works on GNU/Linux > --- > > Key: XERCESC-2135 > URL: https://issues.apache.org/jira/browse/XERCESC-2135 > Project: Xerces-C++ > Issue Type: Improvement > Components: Build >Reporter: Roger Leigh >Priority: Minor > > iconv is built into GNU libc, so is linked with automatically. On non-GNU > systems, it's a standalone library, which we don't link with. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Assigned] (XERCESC-2203) MingGW time functions are broken
[
https://issues.apache.org/jira/browse/XERCESC-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roger Leigh reassigned XERCESC-2203:
Assignee: (was: Roger Leigh)
> MingGW time functions are broken
>
>
> Key: XERCESC-2203
> URL: https://issues.apache.org/jira/browse/XERCESC-2203
> Project: Xerces-C++
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 3.2.0, 3.2.1, 3.2.2, 3.2.3
>Reporter: Roger Leigh
>Priority: Major
> Fix For: 4.0.0
>
>
> {noformat}
> C:/projects/xerces-c/src/xercesc/util/XMLDateTime.cpp:583:29: error: use of
> undeclared identifier 'timezone'
> return mktime() - timezone;
> {noformat}
> Newer versions of MinGW have added functions which were previously missing,
> like gmtime_r and localtime_r. It's possible the autodetection logic is
> incomplete and it's not using the correct ifdefs. For Xalan-C, I added
> additional feature detection and this solved the problem and will work with
> old or new MinGW versions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Assigned] (XERCESC-2167) Do not set SONAME when building shared libs
[
https://issues.apache.org/jira/browse/XERCESC-2167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roger Leigh reassigned XERCESC-2167:
Assignee: (was: Roger Leigh)
> Do not set SONAME when building shared libs
> ---
>
> Key: XERCESC-2167
> URL: https://issues.apache.org/jira/browse/XERCESC-2167
> Project: Xerces-C++
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.2.0, 3.2.1, 3.2.2, 3.2.3
>Reporter: Jeroen
>Priority: Major
>
>
> When building a static library (i.e. building with {{cmake
> -DBUILD_SHARED_LIBS=OFF}}, we should not set a SONAME or rename the library
> file. A static library should just be named libxerces-c.a and not
> libxerces-c-3.2.a (otherwise it won't link with -lxerces-c).
> Here is a very simple example patch:
> [https://patch-diff.githubusercontent.com/raw/jeroen/xerces-c/pull/1.patch]
>
> Thank you!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Assigned] (XERCESC-2164) Failed to link nonstandard OpenSSL libraries location
[
https://issues.apache.org/jira/browse/XERCESC-2164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roger Leigh reassigned XERCESC-2164:
Assignee: (was: Roger Leigh)
> Failed to link nonstandard OpenSSL libraries location
> -
>
> Key: XERCESC-2164
> URL: https://issues.apache.org/jira/browse/XERCESC-2164
> Project: Xerces-C++
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.2.0, 3.2.1, 3.2.2, 3.2.3
> Environment: gcc (Ubuntu 6.5.0-2ubuntu1~16.04) 6.5.0 20181026
> cmake version 3.13.0
>Reporter: SmartNet Club
>Priority: Major
> Labels: easyfix, patch
> Original Estimate: 1h
> Remaining Estimate: 1h
>
>
> {code:java}
> /usr/bin/x86_64-linux-gnu-ld: warning: libssl.so.1.1, needed by
> /CURL/curl-7_63_0/lib/libcurl.so, not found (try using -rpath or -rpath-link)
> /usr/bin/x86_64-linux-gnu-ld: warning: libcrypto.so.1.1, needed by
> /CURL/curl-7_63_0/lib/libcurl.so, not found (try using -rpath or -rpath-link)
> /CURL/curl-7_63_0/lib/libcurl.so: undefined reference to
> `OpenSSL_version_num@OPENSSL_1_1_0'
> {code}
> The problem with src/CMakeLists.txt:1088
>
> {code:java}
> list(APPEND libxerces_c_DEPS ${CURL_LIBRARIES})
> {code}
> ${CURL_LIBRARIES} does not include dependencies
> To fix, should be replaced by CURL::libcurl
>
> {code:java}
> list(APPEND libxerces_c_DEPS CURL::libcurl)
> {code}
> Note:
> To find CURL should be used CURLConfig.cmake from
> /CURL/curl-7_63_0/lib/cmake/CURL
> Standard
> *[CMake|https://github.com/Kitware/CMake]/[Modules|https://github.com/Kitware/CMake/tree/master/Modules]/FindCURL.cmake*
> does not include dependencies into target CURL::libcurl
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Assigned] (XERCESC-2208) Rationalise XercesIntTypes
[ https://issues.apache.org/jira/browse/XERCESC-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh reassigned XERCESC-2208: Assignee: (was: Roger Leigh) > Rationalise XercesIntTypes > -- > > Key: XERCESC-2208 > URL: https://issues.apache.org/jira/browse/XERCESC-2208 > Project: Xerces-C++ > Issue Type: Improvement > Components: Miscellaneous >Reporter: Roger Leigh >Priority: Major > Fix For: 4.0.0 > > > We currently have multiple fallbacks for int types from cstdint, stdint.h, > inttypes.h etc. However, if we require cstdint then we have most of the > basic types guaranteed to be provided, and most of the logic to handle the > fallbacks can be eliminated entirely. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Assigned] (XERCESC-2156) fix static linking with curl
[ https://issues.apache.org/jira/browse/XERCESC-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh reassigned XERCESC-2156: Assignee: (was: Roger Leigh) > fix static linking with curl > > > Key: XERCESC-2156 > URL: https://issues.apache.org/jira/browse/XERCESC-2156 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.0, 3.2.1, 3.2.2, 3.2.3 >Reporter: Fabrice Fontaine >Priority: Minor > Attachments: 0001-fix-static-linking-with-curl.patch > > > When curl is statically built with openssl support, xerces needs to > link with openssl libraries so use pkg_check_modules to get any > needed dependencies > Fixes: > - > http://autobuild.buildroot.org/results/29ca90fff2c8e38f2edf7240eca3aa3fe7397c45 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Assigned] (XERCESC-2206) Use char16_t and unicode literals to replace various XMLCh types
[ https://issues.apache.org/jira/browse/XERCESC-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh reassigned XERCESC-2206: Assignee: (was: Roger Leigh) > Use char16_t and unicode literals to replace various XMLCh types > > > Key: XERCESC-2206 > URL: https://issues.apache.org/jira/browse/XERCESC-2206 > Project: Xerces-C++ > Issue Type: Improvement > Components: Miscellaneous >Reporter: Roger Leigh >Priority: Major > Fix For: 4.0.0 > > > Currently, XMLCh can be a variety of 16-bit types depending upon the > platform, from wchar_t, uint16_t, unsigned short, to char16_t. > To reduce the platform-specific variability, fix XMLCh to char16_t, and also > permit the use of u"" unicode string literals in the codebase. This will > allow replacement of Unicode constants with direct use of literals. > This will additionally reduce the size of the test matrix with only one > character variant to test. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Assigned] (XERCESC-2200) Update AppVeyor image in use
[ https://issues.apache.org/jira/browse/XERCESC-2200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh reassigned XERCESC-2200: Assignee: (was: Roger Leigh) > Update AppVeyor image in use > > > Key: XERCESC-2200 > URL: https://issues.apache.org/jira/browse/XERCESC-2200 > Project: Xerces-C++ > Issue Type: Task > Components: Miscellaneous >Reporter: Roger Leigh >Priority: Major > Fix For: 3.2.4, 4.0.0 > > Original Estimate: 48h > Remaining Estimate: 48h > > AppVeyor images haven't been upgraded for some time. Update to newer image > with VS2019 or VS2017, and switch to vcpkg for ICU and CURL dependencies etc. > which are now provided directly by vcpkg in the AppVeyor images. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Assigned] (XERCESC-2204) Remove message loader
[ https://issues.apache.org/jira/browse/XERCESC-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh reassigned XERCESC-2204: Assignee: (was: Roger Leigh) > Remove message loader > - > > Key: XERCESC-2204 > URL: https://issues.apache.org/jira/browse/XERCESC-2204 > Project: Xerces-C++ > Issue Type: Improvement > Components: Miscellaneous >Reporter: Roger Leigh >Priority: Major > Fix For: 4.0.0 > > > We support several different message loaders (inmemory, icu, iconv). > However... we don't have any translations to actually warrant all this > complexity, and likely never will. We have the basic en_US and that's it. > So this code is essentially unused, and I don't see much prospect of it being > used in the future given that there have been zero translations written in > the last two decades. > In order to reduce the size of the test matrix and reduce the maintenance > burden, I'd like to ask if this is something we could safely drop? > See also XALANC-808 which is the same issue for Xalan-C. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Assigned] (XERCESC-2205) Require std::mutex and std::thread
[ https://issues.apache.org/jira/browse/XERCESC-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh reassigned XERCESC-2205: Assignee: (was: Roger Leigh) > Require std::mutex and std::thread > -- > > Key: XERCESC-2205 > URL: https://issues.apache.org/jira/browse/XERCESC-2205 > Project: Xerces-C++ > Issue Type: Improvement > Components: Miscellaneous >Reporter: Roger Leigh >Priority: Major > Fix For: 4.0.0 > > > Replace the existing MutexManager with the standard library implementation. > This is essentially going to be pthreads or Windows threads under the hood, > so it's effectively replacing PosixMutexManager and WindowsMutexManager with > a single standard replacement. This is currently StdMutexMgr, but rather > than using the MutexManager abstraction, we would be using the standard types > directly. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2236) Dependencies aren't loaded when using provided CMake config package
[
https://issues.apache.org/jira/browse/XERCESC-2236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613131#comment-17613131
]
Roger Leigh commented on XERCESC-2236:
--
The change looks fine to me, and I've applied it to master.
> Dependencies aren't loaded when using provided CMake config package
> ---
>
> Key: XERCESC-2236
> URL: https://issues.apache.org/jira/browse/XERCESC-2236
> Project: Xerces-C++
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.2.3
> Environment: Ubuntu 18.04, CMake 3.22.2
>Reporter: Fred Hornsey
>Assignee: Roger Leigh
>Priority: Major
> Fix For: 3.2.4
>
> Attachments: xercesc-2236-fix.patch
>
>
> We have a CMake config package for our libraries that tries to load Xerces
> support like so:
> {code:java}
> find_package(XercesC PATHS "${OPENDDS_XERCES3}" NO_DEFAULT_PATH)
> if (NOT XercesC_FOUND)
> find_package(XercesC)
> endif(){code}
> Where {{OPENDDS_XERCES3}} is the path to the Xerces our libraries were built
> with. This works on Windows and Linux when using system-provided package.
> When building and installing from source on Linux it seem this doesn't work.
> In this case it's trying to use the CMake package provided by Xerces instead
> of the one builtin to CMake.
> I've created an example to demonstrate this. Xerces is built and installed to
> a location on Linux using CMake. Then we create a {{{}CMakeLists.txt{}}}:
> {code:java}
> cmake_minimum_required(VERSION 3.12.0)
> project(xerces_cmake_config_pkg_test)
> find_package(XercesC PATHS "${THE_XERCES_ROOT}" NO_DEFAULT_PATH)
> add_executable(testexe test.cpp)
> target_link_libraries(testexe XercesC::XercesC)
> {code}
> {{test.cpp}} has to be created, but it doesn't matter what it contains
> because CMake doesn't get far enough to allow us to attempt to build. When
> configuring, setting {{THE_XERCES_ROOT}} to the installed Xerces, CMake gives
> these errors:
> {code:java}
> CMake Error at CMakeLists.txt:10 (add_executable):
> Target "testexe" links to target "ICU::uc" but the target was not found.
> Perhaps a find_package() call is missing for an IMPORTED target, or an
> ALIAS target is missing?
> CMake Error at CMakeLists.txt:10 (add_executable):
> Target "testexe" links to target "ICU::data" but the target was not found.
> Perhaps a find_package() call is missing for an IMPORTED target, or an
> ALIAS target is missing?
> CMake Error at CMakeLists.txt:10 (add_executable):
> Target "testexe" links to target "Threads::Threads" but the target was not
> found. Perhaps a find_package() call is missing for an IMPORTED target, or
> an ALIAS target is missing? {code}
>
> This seems to be caused by the packages being specified by Xerces during its
> configure ([like
> ICU|https://github.com/apache/xerces-c/blob/045bdf8ac7755e1ce2735d5ef3f6741ec4718df9/src/CMakeLists.txt#L1113])
> being referenced in the Config package, but not being loaded for the using
> {{find_package}} or equivalent. [CMake
> documenation|https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#creating-a-package-configuration-file]
> suggests that this should be done in somewhere in the [config
> file|https://github.com/apache/xerces-c/blob/master/src/xercesc/util/XercesVersion.hpp.in].
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2219) XMLReader constructor: memory leak when refreshRawBuffer() throws
[
https://issues.apache.org/jira/browse/XERCESC-2219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17613126#comment-17613126
]
Roger Leigh commented on XERCESC-2219:
--
Yes, this was applied.
> XMLReader constructor: memory leak when refreshRawBuffer() throws
> -
>
> Key: XERCESC-2219
> URL: https://issues.apache.org/jira/browse/XERCESC-2219
> Project: Xerces-C++
> Issue Type: Bug
>Affects Versions: 3.2.3
>Reporter: Roger Leigh
>Assignee: Scott Cantor
>Priority: Major
> Fix For: 4.0.0, 3.2.4
>
>
> See https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=37529 on GDAL
> The backtrace of the exception that caused the memory leak was:
> {noformat}
> Catchpoint 1 (exception thrown), 0x75547672 in __cxa_throw () from
> /lib/x86_64-linux-gnu/libstdc++.so.6
> (gdb) bt
> 0 0x75547672 in __cxa_throw () from
> /lib/x86_64-linux-gnu/libstdc++.so.6
> 1 0x724447c4 in xercesc_4_0::PosixFileMgr::fileRead (this= out>, f=, byteCount=, buffer=,
> manager=0x556df730)
>at xercesc/util/FileManagers/PosixFileMgr.cpp:160
> 2 0x724e6ec2 in xercesc_4_0::XMLReader::refreshRawBuffer
> (this=0x557e49f8) at xercesc/internal/XMLReader.cpp:1891
> 3 0x724e70d4 in xercesc_4_0::XMLReader::XMLReader
> (this=0x557e49f8, pubId=, sysId=0x55750920 u"/",
> streamToAdopt=0x5574e838, from=,
>type=xercesc_4_0::XMLReader::Type_General,
> source=xercesc_4_0::XMLReader::Source_External, throwAtEnd=false,
> calculateSrcOfs=false, lowWaterMark=100,
> version=xercesc_4_0::XMLReader::XMLV1_0,
>manager=0x556df730) at xercesc/internal/XMLReader.cpp:130
> 4 0x724ced75 in xercesc_4_0::ReaderMgr::createReader
> (this=this@entry=0x557896d8, src=...,
> refFrom=refFrom@entry=xercesc_4_0::XMLReader::RefFrom_NonLiteral,
>type=type@entry=xercesc_4_0::XMLReader::Type_General,
> source=source@entry=xercesc_4_0::XMLReader::Source_External,
> calcSrcOfs=false, lowWaterMark=100) at ./xercesc/sax/InputSource.hpp:314
> 5 0x724cb0af in xercesc_4_0::IGXMLScanner::scanReset
> (this=0x55789608, src=...) at xercesc/internal/IGXMLScanner2.cpp:1286
> 6 0x724c36e9 in xercesc_4_0::IGXMLScanner::scanDocument
> (this=0x55789608, src=...) at xercesc/internal/IGXMLScanner.cpp:198
> 7 0x7250abaf in xercesc_4_0::AbstractDOMParser::parse
> (this=0x7fffc2d0, source=...) at xercesc/parsers/AbstractDOMParser.cpp:545
> 8 0x724cbdbe in xercesc_4_0::IGXMLScanner::resolveSchemaGrammar
> (this=0x55792f78, loc=0x557dd694 u"/", uri=0x55737180 u"`",
> ignoreLoadSchema=)
>at xercesc/internal/IGXMLScanner2.cpp:1895
> 0x724cce7c in xercesc_4_0::IGXMLScanner::parseSchemaLocation
> (this=0x55792f78, schemaLocationStr=,
> ignoreLoadSchema=false) at ./xercesc/framework/XMLBuffer.hpp:171
> 10 0x724cd182 in
> xercesc_4_0::IGXMLScanner::scanRawAttrListforNameSpaces
> (this=this@entry=0x55792f78, attCount=attCount@entry=9) at
> xercesc/internal/IGXMLScanner2.cpp:1649
> 11 0x724c22cb in xercesc_4_0::IGXMLScanner::scanStartTagNS
> (this=0x55792f78, gotData=@0x7fffc91f: true) at
> xercesc/internal/IGXMLScanner.cpp:2213
> 12 0x724c3522 in xercesc_4_0::IGXMLScanner::scanContent
> (this=0x55792f78) at xercesc/internal/IGXMLScanner.cpp:890
> 13 0x724c3760 in xercesc_4_0::IGXMLScanner::scanDocument
> (this=0x55792f78, src=...) at xercesc/internal/IGXMLScanner.cpp:217
> 14 0x725158e3 in xercesc_4_0::SAX2XMLReaderImpl::parse
> (this=0x55731828, source=...) at xercesc/parsers/SAX2XMLReaderImpl.cpp:409
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Closed] (XERCESC-2219) XMLReader constructor: memory leak when refreshRawBuffer() throws
[
https://issues.apache.org/jira/browse/XERCESC-2219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roger Leigh closed XERCESC-2219.
Resolution: Fixed
> XMLReader constructor: memory leak when refreshRawBuffer() throws
> -
>
> Key: XERCESC-2219
> URL: https://issues.apache.org/jira/browse/XERCESC-2219
> Project: Xerces-C++
> Issue Type: Bug
>Affects Versions: 3.2.3
>Reporter: Roger Leigh
>Assignee: Scott Cantor
>Priority: Major
> Fix For: 4.0.0, 3.2.4
>
>
> See https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=37529 on GDAL
> The backtrace of the exception that caused the memory leak was:
> {noformat}
> Catchpoint 1 (exception thrown), 0x75547672 in __cxa_throw () from
> /lib/x86_64-linux-gnu/libstdc++.so.6
> (gdb) bt
> 0 0x75547672 in __cxa_throw () from
> /lib/x86_64-linux-gnu/libstdc++.so.6
> 1 0x724447c4 in xercesc_4_0::PosixFileMgr::fileRead (this= out>, f=, byteCount=, buffer=,
> manager=0x556df730)
>at xercesc/util/FileManagers/PosixFileMgr.cpp:160
> 2 0x724e6ec2 in xercesc_4_0::XMLReader::refreshRawBuffer
> (this=0x557e49f8) at xercesc/internal/XMLReader.cpp:1891
> 3 0x724e70d4 in xercesc_4_0::XMLReader::XMLReader
> (this=0x557e49f8, pubId=, sysId=0x55750920 u"/",
> streamToAdopt=0x5574e838, from=,
>type=xercesc_4_0::XMLReader::Type_General,
> source=xercesc_4_0::XMLReader::Source_External, throwAtEnd=false,
> calculateSrcOfs=false, lowWaterMark=100,
> version=xercesc_4_0::XMLReader::XMLV1_0,
>manager=0x556df730) at xercesc/internal/XMLReader.cpp:130
> 4 0x724ced75 in xercesc_4_0::ReaderMgr::createReader
> (this=this@entry=0x557896d8, src=...,
> refFrom=refFrom@entry=xercesc_4_0::XMLReader::RefFrom_NonLiteral,
>type=type@entry=xercesc_4_0::XMLReader::Type_General,
> source=source@entry=xercesc_4_0::XMLReader::Source_External,
> calcSrcOfs=false, lowWaterMark=100) at ./xercesc/sax/InputSource.hpp:314
> 5 0x724cb0af in xercesc_4_0::IGXMLScanner::scanReset
> (this=0x55789608, src=...) at xercesc/internal/IGXMLScanner2.cpp:1286
> 6 0x724c36e9 in xercesc_4_0::IGXMLScanner::scanDocument
> (this=0x55789608, src=...) at xercesc/internal/IGXMLScanner.cpp:198
> 7 0x7250abaf in xercesc_4_0::AbstractDOMParser::parse
> (this=0x7fffc2d0, source=...) at xercesc/parsers/AbstractDOMParser.cpp:545
> 8 0x724cbdbe in xercesc_4_0::IGXMLScanner::resolveSchemaGrammar
> (this=0x55792f78, loc=0x557dd694 u"/", uri=0x55737180 u"`",
> ignoreLoadSchema=)
>at xercesc/internal/IGXMLScanner2.cpp:1895
> 0x724cce7c in xercesc_4_0::IGXMLScanner::parseSchemaLocation
> (this=0x55792f78, schemaLocationStr=,
> ignoreLoadSchema=false) at ./xercesc/framework/XMLBuffer.hpp:171
> 10 0x724cd182 in
> xercesc_4_0::IGXMLScanner::scanRawAttrListforNameSpaces
> (this=this@entry=0x55792f78, attCount=attCount@entry=9) at
> xercesc/internal/IGXMLScanner2.cpp:1649
> 11 0x724c22cb in xercesc_4_0::IGXMLScanner::scanStartTagNS
> (this=0x55792f78, gotData=@0x7fffc91f: true) at
> xercesc/internal/IGXMLScanner.cpp:2213
> 12 0x724c3522 in xercesc_4_0::IGXMLScanner::scanContent
> (this=0x55792f78) at xercesc/internal/IGXMLScanner.cpp:890
> 13 0x724c3760 in xercesc_4_0::IGXMLScanner::scanDocument
> (this=0x55792f78, src=...) at xercesc/internal/IGXMLScanner.cpp:217
> 14 0x725158e3 in xercesc_4_0::SAX2XMLReaderImpl::parse
> (this=0x55731828, source=...) at xercesc/parsers/SAX2XMLReaderImpl.cpp:409
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2231) (windows build) Generated resource file has trailing Nulls which appears to not compile correctly
[
https://issues.apache.org/jira/browse/XERCESC-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17448399#comment-17448399
]
Roger Leigh commented on XERCESC-2231:
--
While the move to CMake may be related, this was all tested extensively and was
shown to result in DLLs with the correct information embedded in them. The odd
stuff with the NULs was directly copied from the existing RC files. If it's
inappropriate then we should remove them entirely.
> (windows build) Generated resource file has trailing Nulls which appears to
> not compile correctly
> -
>
> Key: XERCESC-2231
> URL: https://issues.apache.org/jira/browse/XERCESC-2231
> Project: Xerces-C++
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.2.2, 3.2.3
> Environment: Windows CMAKE build
>Reporter: Rod Widdowson
>Priority: Major
>
> We just noticed this but I suspect it goes back a long way. Our build of
> xerces is notably short of string resources:
> {code:java}
> C:\program files (x86)\shibboleth\sp\lib\xerces-c_3_2.dll:
> Verified: Unsigned
> Link date: 16:29 09/04/2020
> Publisher: n/a
> Company: n/a
> Description: n/a
> Product: n/a
> Prod version: n/a
> File version: n/a
> MachineType: 32-bit
> Binary Version: 3.2.3.0
> Original Name: n/a
> Internal Name: n/a
> Copyright: n/a
> Comments: n/a
> Entropy: 6.231{code}
> I could go back to find out when this started if needs be, but I'd guess it
> started when the project moved to CMAKE.
> the Generated rc file looks suspicious
> {code:java}
> VALUE "Comments", "Dynamic linked library for Xerces-C++\0"
> VALUE "CompanyName", "Apache Software Foundation\0"
> VALUE "FileDescription", "Shared Library for Xerces-C++ Version 3.2.3\0"
> VALUE "FileVersion", "3, 2, 3\0"
> VALUE "InternalName", XERCES_DLL_NAME
> VALUE "LegalCopyright", "Copyright © 1999-2018 Apache Software Foundation;
> subject to licensing terms\0"
> VALUE "LegalTrademarks", "\0"
> VALUE "OriginalFilename", XERCES_DLL_NAME
> VALUE "PrivateBuild", "\0"
> VALUE "ProductName", "Xerces-C++ Version 3.2.3\0"
> VALUE "ProductVersion", "3, 2, 3\0"
> VALUE "SpecialBuild", "\0"
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2220) Winsock Network Accessor does not support https URLs
[
https://issues.apache.org/jira/browse/XERCESC-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17433408#comment-17433408
]
Roger Leigh commented on XERCESC-2220:
--
[~and...@avenza.com] The reason this hasn't been remedied is that no one has
cared sufficiently about it to develop and submit a fix for it. If someone
wishes to do so, I'll be more than happy to review and test it.
As for how to satisfy {{find_package(curl)}}, you need to make sure the CURL
installation is on your {{CMAKE_PREFIX_PATH}} so that it can be searched for
and found successfully. One way to do this is to use _vcpkg _and its toolchain
file, and all of the third-party dependencies can be trivially built and used.
> Winsock Network Accessor does not support https URLs
>
>
> Key: XERCESC-2220
> URL: https://issues.apache.org/jira/browse/XERCESC-2220
> Project: Xerces-C++
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 3.2.3
> Environment: Windows 10
> MinGW 7.3.0 64-bit
>Reporter: Florian Meinicke
>Priority: Major
>
> According to [a
> comment|https://issues.apache.org/jira/browse/XERCESC-2029?focusedCommentId=13982847=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13982847]
> from
> [Xerces-C++/XERCESC-2029|https://issues.apache.org/jira/browse/XERCESC-2029]
> only the curl and winsock network accessors support https URLs.
> While I got everything working on Linux using the curl accessor I cannot do
> so on Windows. I'm still getting the "unsupported protocol in URL" error even
> though I'm using the winsock accessor.
> The problem appears to be that https has been deliberately disabled for the
> winsock accessor:
> Taken from {{src/xercesc/util/NetAccessors/WinSock/WinSockNetAccessor.cpp}}:
> {code:cpp}
> BinInputStream* WinSockNetAccessor::makeNew(const XMLURL& urlSource, const
> XMLNetHTTPInfo* httpInfo /*=0*/)
> {
> XMLURL::Protocols protocol = urlSource.getProtocol();
> switch(protocol)
> {
> case XMLURL::HTTP:
> {
> BinHTTPURLInputStream* retStrm =
> new (urlSource.getMemoryManager())
> BinHTTPURLInputStream(urlSource, httpInfo);
> return retStrm;
> break;
> }
> //
> // These are the only protocols we support now. So throw and
> // unsupported protocol exception for the others.
> //
> default :
> ThrowXMLwithMemMgr(MalformedURLException,
> XMLExcepts::URL_UnsupportedProto, urlSource.getMemoryManager());
> break;
> }
> return 0;
> }
> {code}
> My understanding is that the winsock accessor should support https URLs so
> the question is why is https being disabled in {{WinSockNetAccessor}}?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2225) Link to installed CMake targets of CURL
[ https://issues.apache.org/jira/browse/XERCESC-2225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17417810#comment-17417810 ] Roger Leigh commented on XERCESC-2225: -- XERCESC-2226 added as a followup. > Link to installed CMake targets of CURL > --- > > Key: XERCESC-2225 > URL: https://issues.apache.org/jira/browse/XERCESC-2225 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.3 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > > Match ICU behaviour. > https://github.com/apache/xerces-c/pull/34 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2226) Increment minimum CMake version to 3.12
Roger Leigh created XERCESC-2226: Summary: Increment minimum CMake version to 3.12 Key: XERCESC-2226 URL: https://issues.apache.org/jira/browse/XERCESC-2226 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 3.2.3 Reporter: Roger Leigh Assignee: Roger Leigh Followup for XERCESC-2225 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2225) Link to installed CMake targets of CURL
Roger Leigh created XERCESC-2225: Summary: Link to installed CMake targets of CURL Key: XERCESC-2225 URL: https://issues.apache.org/jira/browse/XERCESC-2225 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 3.2.3 Reporter: Roger Leigh Assignee: Roger Leigh Match ICU behaviour. https://github.com/apache/xerces-c/pull/34 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2219) XMLReader constructor: memory leak when refreshRawBuffer() throws
Roger Leigh created XERCESC-2219:
Summary: XMLReader constructor: memory leak when
refreshRawBuffer() throws
Key: XERCESC-2219
URL: https://issues.apache.org/jira/browse/XERCESC-2219
Project: Xerces-C++
Issue Type: Bug
Affects Versions: 3.2.3
Reporter: Roger Leigh
Assignee: Roger Leigh
See https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=37529 on GDAL
The backtrace of the exception that caused the memory leak was:
{noformat}
Catchpoint 1 (exception thrown), 0x75547672 in __cxa_throw () from
/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt
0 0x75547672 in __cxa_throw () from
/lib/x86_64-linux-gnu/libstdc++.so.6
1 0x724447c4 in xercesc_4_0::PosixFileMgr::fileRead (this=, f=, byteCount=, buffer=,
manager=0x556df730)
at xercesc/util/FileManagers/PosixFileMgr.cpp:160
2 0x724e6ec2 in xercesc_4_0::XMLReader::refreshRawBuffer
(this=0x557e49f8) at xercesc/internal/XMLReader.cpp:1891
3 0x724e70d4 in xercesc_4_0::XMLReader::XMLReader
(this=0x557e49f8, pubId=, sysId=0x55750920 u"/",
streamToAdopt=0x5574e838, from=,
type=xercesc_4_0::XMLReader::Type_General,
source=xercesc_4_0::XMLReader::Source_External, throwAtEnd=false,
calculateSrcOfs=false, lowWaterMark=100,
version=xercesc_4_0::XMLReader::XMLV1_0,
manager=0x556df730) at xercesc/internal/XMLReader.cpp:130
4 0x724ced75 in xercesc_4_0::ReaderMgr::createReader
(this=this@entry=0x557896d8, src=...,
refFrom=refFrom@entry=xercesc_4_0::XMLReader::RefFrom_NonLiteral,
type=type@entry=xercesc_4_0::XMLReader::Type_General,
source=source@entry=xercesc_4_0::XMLReader::Source_External, calcSrcOfs=false,
lowWaterMark=100) at ./xercesc/sax/InputSource.hpp:314
5 0x724cb0af in xercesc_4_0::IGXMLScanner::scanReset
(this=0x55789608, src=...) at xercesc/internal/IGXMLScanner2.cpp:1286
6 0x724c36e9 in xercesc_4_0::IGXMLScanner::scanDocument
(this=0x55789608, src=...) at xercesc/internal/IGXMLScanner.cpp:198
7 0x7250abaf in xercesc_4_0::AbstractDOMParser::parse
(this=0x7fffc2d0, source=...) at xercesc/parsers/AbstractDOMParser.cpp:545
8 0x724cbdbe in xercesc_4_0::IGXMLScanner::resolveSchemaGrammar
(this=0x55792f78, loc=0x557dd694 u"/", uri=0x55737180 u"`",
ignoreLoadSchema=)
at xercesc/internal/IGXMLScanner2.cpp:1895
0x724cce7c in xercesc_4_0::IGXMLScanner::parseSchemaLocation
(this=0x55792f78, schemaLocationStr=,
ignoreLoadSchema=false) at ./xercesc/framework/XMLBuffer.hpp:171
10 0x724cd182 in
xercesc_4_0::IGXMLScanner::scanRawAttrListforNameSpaces
(this=this@entry=0x55792f78, attCount=attCount@entry=9) at
xercesc/internal/IGXMLScanner2.cpp:1649
11 0x724c22cb in xercesc_4_0::IGXMLScanner::scanStartTagNS
(this=0x55792f78, gotData=@0x7fffc91f: true) at
xercesc/internal/IGXMLScanner.cpp:2213
12 0x724c3522 in xercesc_4_0::IGXMLScanner::scanContent
(this=0x55792f78) at xercesc/internal/IGXMLScanner.cpp:890
13 0x724c3760 in xercesc_4_0::IGXMLScanner::scanDocument
(this=0x55792f78, src=...) at xercesc/internal/IGXMLScanner.cpp:217
14 0x725158e3 in xercesc_4_0::SAX2XMLReaderImpl::parse
(this=0x55731828, source=...) at xercesc/parsers/SAX2XMLReaderImpl.cpp:409
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2218) CurlURLInputStream constructor memory leak
Roger Leigh created XERCESC-2218: Summary: CurlURLInputStream constructor memory leak Key: XERCESC-2218 URL: https://issues.apache.org/jira/browse/XERCESC-2218 Project: Xerces-C++ Issue Type: Bug Affects Versions: 3.2.3 Reporter: Roger Leigh Assignee: Roger Leigh CurlURLInputStream constructor calls the readMore() method, which can throw exceptions. In that situation, the destructor is not called, which results in resource/memory leaks. To fix that, catch the exceptions, manually do the cleanup and rethrow the exceptions. Found by ossfuzz (locally) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2217) ICUTranscoder::transcodeFrom buffer overflow
Roger Leigh created XERCESC-2217: Summary: ICUTranscoder::transcodeFrom buffer overflow Key: XERCESC-2217 URL: https://issues.apache.org/jira/browse/XERCESC-2217 Project: Xerces-C++ Issue Type: Bug Affects Versions: 3.2.3 Reporter: Roger Leigh Assignee: Roger Leigh See https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=35373 When charsDecoded == 0, the line for (index = 0; index < charsDecoded - 1; index++) will cause to read out of bounds of fSrcOffsets, due to unsigned integer underflow rules. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2141) Enable C++11/14/17 with autoconf build and CMake build
[ https://issues.apache.org/jira/browse/XERCESC-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2141: - Fix Version/s: (was: 3.3.0) 4.0.0 > Enable C++11/14/17 with autoconf build and CMake build > -- > > Key: XERCESC-2141 > URL: https://issues.apache.org/jira/browse/XERCESC-2141 > Project: Xerces-C++ > Issue Type: Improvement > Components: Build >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Labels: autoconf, build, c++11, c++14, c++17 > Fix For: 4.0.0 > > Attachments: 0001-autoconf-Enable-C-14-or-C-11-when-available.patch > > > The CMake build will try to put the compiler in C++14 mode, falling back to > C++11 then C++98. The autoconf build doesn't do this, and the attached patch > makes the behaviour match so both build systems will use the same fallbacks. > Current compilers default to C++14. Very old compilers have no support for > C++11 or C++14. But compilers in between support it, but not by default. > This adds the feature tests to check for such support and enable it when > available. > The CMake C++ standard support is user-configurable by setting the > CMAKE_CXX_STANDARD setting. Autoconf doesn't provide any way to do this, so > the feature enabling isn't explicitly overridable. I'm not sure if that's > too problematic. The main compatibility concern might be if this causes an > ABI break with use of C++11/14 library features like the new string type. > However, we aren't making use of any of these features. The main change > would be the XMLCh type switch from uint16_t to char16_t. I'm not sure what > the Xerces policy for such changes has been in the past. Any thoughts? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2202) Update version of master branch to 3.3.0
[ https://issues.apache.org/jira/browse/XERCESC-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2202: - Fix Version/s: (was: 3.3.0) 4.0.0 > Update version of master branch to 3.3.0 > > > Key: XERCESC-2202 > URL: https://issues.apache.org/jira/browse/XERCESC-2202 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 4.0.0 > > Original Estimate: 1h > Remaining Estimate: 1h > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2201) Update Travis-CI image in use
[ https://issues.apache.org/jira/browse/XERCESC-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2201: - Fix Version/s: (was: 3.3.0) 4.0.0 > Update Travis-CI image in use > - > > Key: XERCESC-2201 > URL: https://issues.apache.org/jira/browse/XERCESC-2201 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 4.0.0 > > Original Estimate: 24h > Remaining Estimate: 24h > > Update image to use current image e.g. Ubuntu 20.04 LTS, which should see us > supported for some time into the future. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2200) Update AppVeyor image in use
[ https://issues.apache.org/jira/browse/XERCESC-2200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2200: - Fix Version/s: (was: 3.3.0) 4.0.0 > Update AppVeyor image in use > > > Key: XERCESC-2200 > URL: https://issues.apache.org/jira/browse/XERCESC-2200 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 4.0.0 > > Original Estimate: 48h > Remaining Estimate: 48h > > AppVeyor images haven't been upgraded for some time. Update to newer image > with VS2019 or VS2017, and switch to vcpkg for ICU and CURL dependencies etc. > which are now provided directly by vcpkg in the AppVeyor images. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2203) MingGW time functions are broken
[
https://issues.apache.org/jira/browse/XERCESC-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roger Leigh updated XERCESC-2203:
-
Fix Version/s: (was: 3.3.0)
4.0.0
> MingGW time functions are broken
>
>
> Key: XERCESC-2203
> URL: https://issues.apache.org/jira/browse/XERCESC-2203
> Project: Xerces-C++
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 3.3.0
>Reporter: Roger Leigh
>Assignee: Roger Leigh
>Priority: Major
> Fix For: 4.0.0
>
>
> {noformat}
> C:/projects/xerces-c/src/xercesc/util/XMLDateTime.cpp:583:29: error: use of
> undeclared identifier 'timezone'
> return mktime() - timezone;
> {noformat}
> Newer versions of MinGW have added functions which were previously missing,
> like gmtime_r and localtime_r. It's possible the autodetection logic is
> incomplete and it's not using the correct ifdefs. For Xalan-C, I added
> additional feature detection and this solved the problem and will work with
> old or new MinGW versions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2210) Remove XERCES_NO_MATCHING_DELETE_OPERATOR
[ https://issues.apache.org/jira/browse/XERCESC-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2210: - Fix Version/s: (was: 3.3.0) 4.0.0 > Remove XERCES_NO_MATCHING_DELETE_OPERATOR > - > > Key: XERCESC-2210 > URL: https://issues.apache.org/jira/browse/XERCESC-2210 > Project: Xerces-C++ > Issue Type: Bug > Components: Build, Miscellaneous >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 4.0.0 > > > XERCES_NO_MATCHING_DELETE_OPERATOR is checked for by both autoconf and cmake. > It is used in XMemory and DOMDocumentImpl. > Any conforming compiler from this century should be perfectly capable of > providing a proper operator delete, since it's a fundamental requirement for > all the standard containers. This check is thoroughly obsolete. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2208) Rationalise XercesIntTypes
[ https://issues.apache.org/jira/browse/XERCESC-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2208: - Fix Version/s: (was: 3.3.0) 4.0.0 > Rationalise XercesIntTypes > -- > > Key: XERCESC-2208 > URL: https://issues.apache.org/jira/browse/XERCESC-2208 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 4.0.0 > > > We currently have multiple fallbacks for int types from cstdint, stdint.h, > inttypes.h etc. However, if we require cstdint then we have most of the > basic types guaranteed to be provided, and most of the logic to handle the > fallbacks can be eliminated entirely. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2205) Require std::mutex and std::thread
[ https://issues.apache.org/jira/browse/XERCESC-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2205: - Fix Version/s: (was: 3.3.0) 4.0.0 > Require std::mutex and std::thread > -- > > Key: XERCESC-2205 > URL: https://issues.apache.org/jira/browse/XERCESC-2205 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 4.0.0 > > > Replace the existing MutexManager with the standard library implementation. > This is essentially going to be pthreads or Windows threads under the hood, > so it's effectively replacing PosixMutexManager and WindowsMutexManager with > a single standard replacement. This is currently StdMutexMgr, but rather > than using the MutexManager abstraction, we would be using the standard types > directly. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2207) Rationalise network accessors
[ https://issues.apache.org/jira/browse/XERCESC-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2207: - Fix Version/s: (was: 3.3.0) 4.0.0 > Rationalise network accessors > - > > Key: XERCESC-2207 > URL: https://issues.apache.org/jira/browse/XERCESC-2207 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Priority: Major > Fix For: 4.0.0 > > > We currently support four netaccessors: curl, winsock, socket and cfurl. And > also "none" if network support is disabled. > This makes the test matrix quite large. Additionally, with the recent push > to use HTTPS everywhere, I wonder about the dangers of Xerces using its own > plain HTTP implementation over sockets without any SSL support. > Would dropping socket and winsock, and requiring curl or cfurl make sense? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2208) Rationalise XercesIntTypes
[ https://issues.apache.org/jira/browse/XERCESC-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17134809#comment-17134809 ] Roger Leigh commented on XERCESC-2208: -- Please see open pull request for this change. * Unconditionally use . Also use and . * Remove Autoconf and CMake integer checks, along with some other unused header checks and defines present in Xerces_autoconf_config.hpp * Move constant type definitions out of Xerces_autoconf_config.hpp into XercesDefs.hpp * UTF16Ch and UCS4Ch are typedefs for char16_t and char32_t, so are now using the language types specifically intended for the purpose * XSValue now uses fixed-size integer types, so its behaviour will be the same across all platforms. Some review, testing and feedback would certainly be appreciated. In particular, testing on a 32-bit platform would be very useful. > Rationalise XercesIntTypes > -- > > Key: XERCESC-2208 > URL: https://issues.apache.org/jira/browse/XERCESC-2208 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 3.3.0 > > > We currently have multiple fallbacks for int types from cstdint, stdint.h, > inttypes.h etc. However, if we require cstdint then we have most of the > basic types guaranteed to be provided, and most of the logic to handle the > fallbacks can be eliminated entirely. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Assigned] (XERCESC-2208) Rationalise XercesIntTypes
[ https://issues.apache.org/jira/browse/XERCESC-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh reassigned XERCESC-2208: Assignee: Roger Leigh > Rationalise XercesIntTypes > -- > > Key: XERCESC-2208 > URL: https://issues.apache.org/jira/browse/XERCESC-2208 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 3.3.0 > > > We currently have multiple fallbacks for int types from cstdint, stdint.h, > inttypes.h etc. However, if we require cstdint then we have most of the > basic types guaranteed to be provided, and most of the logic to handle the > fallbacks can be eliminated entirely. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2204) Remove message loader
[
https://issues.apache.org/jira/browse/XERCESC-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17134558#comment-17134558
]
Roger Leigh commented on XERCESC-2204:
--
Since this is all abstracted via the msgloader interface, it won't in and of
itself cause an ABI or API break; there will always be inmemory to fall back on.
If there are any users of ICU msgloader and they have done their own custom
build with their own custom messages added in then this would certainly break.
As far as I can see, they aren't loaded dynamically at runtime; they all get
generated and linked in at compile time. But maybe it's more flexible than
that and I haven't looked closely enough.
I have nothing against internationalisation; most of the stuff I work on is
fully internationalised with multiple languages. But here, in Xerces-C we
don't just have one translation system. We have *three*. All apparently
unused.
Just to pick a string at random:
{noformat}
$ git grep "unknown complexType '{0}'"
src/xercesc/NLS/EN_US/XMLErrList_EN_US.Xml:
src/xercesc/util/MsgLoaders/ICU/resources/root.txt: "unknown
complexType '{0}'" ,
src/xercesc/util/MsgLoaders/MsgCatalog/XercesMessages_en_US.Msg:37 unknown
complexType '{0}'
{noformat}
So we don't just have one set of translations. We have three. Just for en_US!
If we were to keep the translation machinery, I think it would make sense to
pick one and require it. The iconv (catgets) one is UNIX-specific. The
inmemory one is limited to a single language. ICU is the most flexible, but
requires ICU. But then, ICU is useful for proper Unicode support. If we were
to require ICU unconditionally, then we could use the ICU message loader
unconditionally.
It's all horribly complicated compared with gettext.
Regarding overall goals, I would like to modernise some parts of Xerces-C++,
primarily to make it more usable with current compilers and more easily
interoperable with current libraries, and also to improve correctness and
performance. I'm certainly not envisaging any world-breaking rewrite. Rather,
some very selective rationalisation of features, requiring a selected subset of
C++11, and being very careful about avoiding introducing compatibility problems
or introducing bugs. With those changes made, I would be interested in running
clang-tidy over the codebase and fixing any latent bugs it uncovers. There are
a lot of casting issues (over 10k). Many of them can be removed by introducing
mutable; previously avoided due to broken compilers, but would eliminate a lot
of casting away of constness. I did run a static analyser over the whole
codebase. Too many issues to fix in one go; it will need to be broken down
into categories of issues and tackled bit by bit. We're not at that point yet;
that will need additional issues creating once we're at the point of being able
to run the analyser properly.
> Remove message loader
> -
>
> Key: XERCESC-2204
> URL: https://issues.apache.org/jira/browse/XERCESC-2204
> Project: Xerces-C++
> Issue Type: Bug
> Components: Miscellaneous
>Affects Versions: 3.3.0
>Reporter: Roger Leigh
>Assignee: Roger Leigh
>Priority: Major
> Fix For: 3.3.0
>
>
> We support several different message loaders (inmemory, icu, iconv).
> However... we don't have any translations to actually warrant all this
> complexity, and likely never will. We have the basic en_US and that's it.
> So this code is essentially unused, and I don't see much prospect of it being
> used in the future given that there have been zero translations written in
> the last two decades.
> In order to reduce the size of the test matrix and reduce the maintenance
> burden, I'd like to ask if this is something we could safely drop?
> See also XALANC-808 which is the same issue for Xalan-C.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2200) Update AppVeyor image in use
[ https://issues.apache.org/jira/browse/XERCESC-2200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17134554#comment-17134554 ] Roger Leigh commented on XERCESC-2200: -- I'll be able to upgrade the AppVeyor image and enable vcpkg-based ICU once https://github.com/microsoft/vcpkg/pull/11897 is merged. > Update AppVeyor image in use > > > Key: XERCESC-2200 > URL: https://issues.apache.org/jira/browse/XERCESC-2200 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 3.3.0 > > Original Estimate: 48h > Remaining Estimate: 48h > > AppVeyor images haven't been upgraded for some time. Update to newer image > with VS2019 or VS2017, and switch to vcpkg for ICU and CURL dependencies etc. > which are now provided directly by vcpkg in the AppVeyor images. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2206) Use char16_t and unicode literals to replace various XMLCh types
[ https://issues.apache.org/jira/browse/XERCESC-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17133691#comment-17133691 ] Roger Leigh commented on XERCESC-2206: -- There would certainly be no urgency in releasing what's on the master branch. We could potentially stage the changes there and leave it until next year, and maybe also queue up any breaking changes which couldn't be applied for compatibility reasons before now for 3.2. This would permit us to do the work without committing to support two releases at the same time, if that would be acceptable? In benchmarking my application code, I've found that over 50% of the total CPU time could end up spent in transcoding, and a big part of that was conversion of UTF-8 to UTF-16 as input to Xerces-C++ and then more for reconversion of the output. If it were possible, I'd find much more value in UTF-8 end-to-end without involving UTF-16 or UTF-32. But being able to use UTF-16 literals and std::ustring directly would reduce the overheads by a fairly significant amount. > Use char16_t and unicode literals to replace various XMLCh types > > > Key: XERCESC-2206 > URL: https://issues.apache.org/jira/browse/XERCESC-2206 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 3.3.0 > > > Currently, XMLCh can be a variety of 16-bit types depending upon the > platform, from wchar_t, uint16_t, unsigned short, to char16_t. > To reduce the platform-specific variability, fix XMLCh to char16_t, and also > permit the use of u"" unicode string literals in the codebase. This will > allow replacement of Unicode constants with direct use of literals. > This will additionally reduce the size of the test matrix with only one > character variant to test. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2209) Remove HAVE_LSTRING
[ https://issues.apache.org/jira/browse/XERCESC-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh resolved XERCESC-2209. -- Resolution: Fixed > Remove HAVE_LSTRING > --- > > Key: XERCESC-2209 > URL: https://issues.apache.org/jira/browse/XERCESC-2209 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 3.3.0 > > > HAVE_LSTRING is checked for by both autoconf and cmake. However, it's not > used anywhere, so can be safely dropped. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2210) Remove XERCES_NO_MATCHING_DELETE_OPERATOR
[ https://issues.apache.org/jira/browse/XERCESC-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh resolved XERCESC-2210. -- Resolution: Fixed > Remove XERCES_NO_MATCHING_DELETE_OPERATOR > - > > Key: XERCESC-2210 > URL: https://issues.apache.org/jira/browse/XERCESC-2210 > Project: Xerces-C++ > Issue Type: Bug > Components: Build, Miscellaneous >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 3.3.0 > > > XERCES_NO_MATCHING_DELETE_OPERATOR is checked for by both autoconf and cmake. > It is used in XMemory and DOMDocumentImpl. > Any conforming compiler from this century should be perfectly capable of > providing a proper operator delete, since it's a fundamental requirement for > all the standard containers. This check is thoroughly obsolete. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2204) Remove message loader
[ https://issues.apache.org/jira/browse/XERCESC-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17132685#comment-17132685 ] Roger Leigh commented on XERCESC-2204: -- In practice, most distributions providing Xerces-C++ are using "inmemory" since it's the simplest and has no additional external dependencies, and it's platform-independent. In the first instance, we could drop the "icu" and "iconv" message loaders without any loss of functionality, and retain "inmemory". We could do this in two steps: (1) change the CI to inmemory across the board to check it's not breaking anything and then (2) remove the "icu" and "iconv" configuration options and supporting code. If we wanted to, we could later drop the translation machinery entirely, but the above would be noninvasive and simple. > Remove message loader > - > > Key: XERCESC-2204 > URL: https://issues.apache.org/jira/browse/XERCESC-2204 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 3.3.0 > > > We support several different message loaders (inmemory, icu, iconv). > However... we don't have any translations to actually warrant all this > complexity, and likely never will. We have the basic en_US and that's it. > So this code is essentially unused, and I don't see much prospect of it being > used in the future given that there have been zero translations written in > the last two decades. > In order to reduce the size of the test matrix and reduce the maintenance > burden, I'd like to ask if this is something we could safely drop? > See also XALANC-808 which is the same issue for Xalan-C. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2200) Update AppVeyor image in use
[ https://issues.apache.org/jira/browse/XERCESC-2200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17132681#comment-17132681 ] Roger Leigh commented on XERCESC-2200: -- [~scantor] I also applied a minimal version of this fix to xerces-3.2 to restore AppVeyor CI support there as well as on master, since it was broken after ICU changed their source download URLs. > Update AppVeyor image in use > > > Key: XERCESC-2200 > URL: https://issues.apache.org/jira/browse/XERCESC-2200 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 3.3.0 > > Original Estimate: 48h > Remaining Estimate: 48h > > AppVeyor images haven't been upgraded for some time. Update to newer image > with VS2019 or VS2017, and switch to vcpkg for ICU and CURL dependencies etc. > which are now provided directly by vcpkg in the AppVeyor images. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2206) Use char16_t and unicode literals to replace various XMLCh types
[ https://issues.apache.org/jira/browse/XERCESC-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17132650#comment-17132650 ] Roger Leigh commented on XERCESC-2206: -- I certainly don't want to proceed with anything if it will cause you problems. My understanding from earlier conversations was that branching off xerces-3.2 would unblock such changes on the master branch, so that they wouldn't be disruptive for the stable release. Apologies if I've misunderstood. The changes I have made so far on master bring the language requirement up to C++98, and some of these changes would raise it up to C++11. If we need to discuss that further e.g. on the mailing list with a wider audience or in person, I'll be happy to do so. The intent is to make the library easier and more convenient to use, rather than causing unnecessary pain. Some of the tickets I've opened, such as XERCESC-2204 are more for discussion than any immediate action. The overriding intent for these is to minimise the combinatorial explosion of interacting configuration options to maximise test coverage and to minimise the maintenance required so that an end user is not going to get an untested combination. > Use char16_t and unicode literals to replace various XMLCh types > > > Key: XERCESC-2206 > URL: https://issues.apache.org/jira/browse/XERCESC-2206 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 3.3.0 > > > Currently, XMLCh can be a variety of 16-bit types depending upon the > platform, from wchar_t, uint16_t, unsigned short, to char16_t. > To reduce the platform-specific variability, fix XMLCh to char16_t, and also > permit the use of u"" unicode string literals in the codebase. This will > allow replacement of Unicode constants with direct use of literals. > This will additionally reduce the size of the test matrix with only one > character variant to test. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2206) Use char16_t and unicode literals to replace various XMLCh types
[ https://issues.apache.org/jira/browse/XERCESC-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17130670#comment-17130670 ] Roger Leigh commented on XERCESC-2206: -- None of this is intended to cause any *API* break. But if there's any question of needing it to be parallel installable, we could make this preparatory work for a version 4.0 so that distributors can have xerces-c3 and xerces-c4 co-installable. For the few bugfixes and security updates which need applying, it won't be too much work to apply them to both branches. My intent here is to make Xerces-C++ viable for the longer term by making it transparently usable with contemporary compilers and standard libraries from the last decade, rather than have it stuck in the pre-Standard mid-90s-era which is mutually incompatible with the rest of the C++ world. I am not suggesting using C++20 or C++17, or anything remotely bleeding edge. We would be using a strictly limited subset of features, which currently would be: char16_t, thread and eventually optional use of streams and the standard exception types, and possibly ustring. None of those changes are intended to cause any breakage for existing C++ code using Xerces-C++. The char16_t change should be entirely transparent since it's already in 3.2.x if the compiler supports it, and is tested against most open source Xerces-C++ users. What it will enable is the guaranteed ability to utilise unicode literals and string literals in code calling Xerces which will make applications simpler and more readable. > Use char16_t and unicode literals to replace various XMLCh types > > > Key: XERCESC-2206 > URL: https://issues.apache.org/jira/browse/XERCESC-2206 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 3.3.0 > > > Currently, XMLCh can be a variety of 16-bit types depending upon the > platform, from wchar_t, uint16_t, unsigned short, to char16_t. > To reduce the platform-specific variability, fix XMLCh to char16_t, and also > permit the use of u"" unicode string literals in the codebase. This will > allow replacement of Unicode constants with direct use of literals. > This will additionally reduce the size of the test matrix with only one > character variant to test. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2206) Use char16_t and unicode literals to replace various XMLCh types
[ https://issues.apache.org/jira/browse/XERCESC-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17130630#comment-17130630 ] Roger Leigh commented on XERCESC-2206: -- I have deliberately set the version to 3.3 so this is solely for the "master" branch and not intended to disrupt the "xerces-3.2" branch; likewise for all the issues created today. > Use char16_t and unicode literals to replace various XMLCh types > > > Key: XERCESC-2206 > URL: https://issues.apache.org/jira/browse/XERCESC-2206 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 3.3.0 > > > Currently, XMLCh can be a variety of 16-bit types depending upon the > platform, from wchar_t, uint16_t, unsigned short, to char16_t. > To reduce the platform-specific variability, fix XMLCh to char16_t, and also > permit the use of u"" unicode string literals in the codebase. This will > allow replacement of Unicode constants with direct use of literals. > This will additionally reduce the size of the test matrix with only one > character variant to test. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2210) Remove XERCES_NO_MATCHING_DELETE_OPERATOR
Roger Leigh created XERCESC-2210: Summary: Remove XERCES_NO_MATCHING_DELETE_OPERATOR Key: XERCESC-2210 URL: https://issues.apache.org/jira/browse/XERCESC-2210 Project: Xerces-C++ Issue Type: Bug Components: Build, Miscellaneous Affects Versions: 3.3.0 Reporter: Roger Leigh Assignee: Roger Leigh Fix For: 3.3.0 XERCES_NO_MATCHING_DELETE_OPERATOR is checked for by both autoconf and cmake. It is used in XMemory and DOMDocumentImpl. Any conforming compiler from this century should be perfectly capable of providing a proper operator delete, since it's a fundamental requirement for all the standard containers. This check is thoroughly obsolete. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2209) Remove HAVE_LSTRING
Roger Leigh created XERCESC-2209: Summary: Remove HAVE_LSTRING Key: XERCESC-2209 URL: https://issues.apache.org/jira/browse/XERCESC-2209 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 3.3.0 Reporter: Roger Leigh Assignee: Roger Leigh Fix For: 3.3.0 HAVE_LSTRING is checked for by both autoconf and cmake. However, it's not used anywhere, so can be safely dropped. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2208) Rationalise XercesIntTypes
Roger Leigh created XERCESC-2208: Summary: Rationalise XercesIntTypes Key: XERCESC-2208 URL: https://issues.apache.org/jira/browse/XERCESC-2208 Project: Xerces-C++ Issue Type: Bug Components: Miscellaneous Affects Versions: 3.3.0 Reporter: Roger Leigh Fix For: 3.3.0 We currently have multiple fallbacks for int types from cstdint, stdint.h, inttypes.h etc. However, if we require cstdint then we have most of the basic types guaranteed to be provided, and most of the logic to handle the fallbacks can be eliminated entirely. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2207) Rationalise network accessors
Roger Leigh created XERCESC-2207: Summary: Rationalise network accessors Key: XERCESC-2207 URL: https://issues.apache.org/jira/browse/XERCESC-2207 Project: Xerces-C++ Issue Type: Bug Components: Miscellaneous Affects Versions: 3.3.0 Reporter: Roger Leigh Fix For: 3.3.0 We currently support four netaccessors: curl, winsock, socket and cfurl. And also "none" if network support is disabled. This makes the test matrix quite large. Additionally, with the recent push to use HTTPS everywhere, I wonder about the dangers of Xerces using its own plain HTTP implementation over sockets without any SSL support. Would dropping socket and winsock, and requiring curl or cfurl make sense? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2206) Use char16_t and unicode literals to replace various XMLCh types
Roger Leigh created XERCESC-2206: Summary: Use char16_t and unicode literals to replace various XMLCh types Key: XERCESC-2206 URL: https://issues.apache.org/jira/browse/XERCESC-2206 Project: Xerces-C++ Issue Type: Bug Components: Miscellaneous Affects Versions: 3.3.0 Reporter: Roger Leigh Assignee: Roger Leigh Fix For: 3.3.0 Currently, XMLCh can be a variety of 16-bit types depending upon the platform, from wchar_t, uint16_t, unsigned short, to char16_t. To reduce the platform-specific variability, fix XMLCh to char16_t, and also permit the use of u"" unicode string literals in the codebase. This will allow replacement of Unicode constants with direct use of literals. This will additionally reduce the size of the test matrix with only one character variant to test. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2205) Require std::mutex and std::thread
Roger Leigh created XERCESC-2205: Summary: Require std::mutex and std::thread Key: XERCESC-2205 URL: https://issues.apache.org/jira/browse/XERCESC-2205 Project: Xerces-C++ Issue Type: Bug Components: Miscellaneous Affects Versions: 3.3.0 Reporter: Roger Leigh Assignee: Roger Leigh Fix For: 3.3.0 Replace the existing MutexManager with the standard library implementation. This is essentially going to be pthreads or Windows threads under the hood, so it's effectively replacing PosixMutexManager and WindowsMutexManager with a single standard replacement. This is currently StdMutexMgr, but rather than using the MutexManager abstraction, we would be using the standard types directly. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2204) Remove message loader
Roger Leigh created XERCESC-2204: Summary: Remove message loader Key: XERCESC-2204 URL: https://issues.apache.org/jira/browse/XERCESC-2204 Project: Xerces-C++ Issue Type: Bug Components: Miscellaneous Affects Versions: 3.3.0 Reporter: Roger Leigh Assignee: Roger Leigh Fix For: 3.3.0 We support several different message loaders (inmemory, icu, iconv). However... we don't have any translations to actually warrant all this complexity, and likely never will. We have the basic en_US and that's it. So this code is essentially unused, and I don't see much prospect of it being used in the future given that there have been zero translations written in the last two decades. In order to reduce the size of the test matrix and reduce the maintenance burden, I'd like to ask if this is something we could safely drop? See also XALANC-808 which is the same issue for Xalan-C. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2203) MingGW time functions are broken
Roger Leigh created XERCESC-2203:
Summary: MingGW time functions are broken
Key: XERCESC-2203
URL: https://issues.apache.org/jira/browse/XERCESC-2203
Project: Xerces-C++
Issue Type: Bug
Components: Utilities
Affects Versions: 3.3.0
Reporter: Roger Leigh
Assignee: Roger Leigh
Fix For: 3.3.0
{noformat}
C:/projects/xerces-c/src/xercesc/util/XMLDateTime.cpp:583:29: error: use of
undeclared identifier 'timezone'
return mktime() - timezone;
{noformat}
Newer versions of MinGW have added functions which were previously missing,
like gmtime_r and localtime_r. It's possible the autodetection logic is
incomplete and it's not using the correct ifdefs. For Xalan-C, I added
additional feature detection and this solved the problem and will work with old
or new MinGW versions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2201) Update Travis-CI image in use
[ https://issues.apache.org/jira/browse/XERCESC-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh resolved XERCESC-2201. -- Resolution: Fixed > Update Travis-CI image in use > - > > Key: XERCESC-2201 > URL: https://issues.apache.org/jira/browse/XERCESC-2201 > Project: Xerces-C++ > Issue Type: Bug > Components: Miscellaneous >Affects Versions: 3.3.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 3.3.0 > > Original Estimate: 24h > Remaining Estimate: 24h > > Update image to use current image e.g. Ubuntu 20.04 LTS, which should see us > supported for some time into the future. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2141) Enable C++11/14/17 with autoconf build and CMake build
[ https://issues.apache.org/jira/browse/XERCESC-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh resolved XERCESC-2141. -- Resolution: Fixed > Enable C++11/14/17 with autoconf build and CMake build > -- > > Key: XERCESC-2141 > URL: https://issues.apache.org/jira/browse/XERCESC-2141 > Project: Xerces-C++ > Issue Type: Improvement > Components: Build >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Labels: autoconf, build, c++11, c++14, c++17 > Fix For: 3.3.0 > > Attachments: 0001-autoconf-Enable-C-14-or-C-11-when-available.patch > > > The CMake build will try to put the compiler in C++14 mode, falling back to > C++11 then C++98. The autoconf build doesn't do this, and the attached patch > makes the behaviour match so both build systems will use the same fallbacks. > Current compilers default to C++14. Very old compilers have no support for > C++11 or C++14. But compilers in between support it, but not by default. > This adds the feature tests to check for such support and enable it when > available. > The CMake C++ standard support is user-configurable by setting the > CMAKE_CXX_STANDARD setting. Autoconf doesn't provide any way to do this, so > the feature enabling isn't explicitly overridable. I'm not sure if that's > too problematic. The main compatibility concern might be if this causes an > ABI break with use of C++11/14 library features like the new string type. > However, we aren't making use of any of these features. The main change > would be the XMLCh type switch from uint16_t to char16_t. I'm not sure what > the Xerces policy for such changes has been in the past. Any thoughts? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2141) Enable C++11/14/17 with autoconf build and CMake build
[ https://issues.apache.org/jira/browse/XERCESC-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17124275#comment-17124275 ] Roger Leigh commented on XERCESC-2141: -- In the interim, contemporary compilers are going to be enabling C++17 by default, so I've added this in addition to C++11 and C++14 for both Autoconf and CMake. > Enable C++11/14/17 with autoconf build and CMake build > -- > > Key: XERCESC-2141 > URL: https://issues.apache.org/jira/browse/XERCESC-2141 > Project: Xerces-C++ > Issue Type: Improvement > Components: Build >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Labels: autoconf, build, c++11, c++14, c++17 > Fix For: 3.3.0 > > Attachments: 0001-autoconf-Enable-C-14-or-C-11-when-available.patch > > > The CMake build will try to put the compiler in C++14 mode, falling back to > C++11 then C++98. The autoconf build doesn't do this, and the attached patch > makes the behaviour match so both build systems will use the same fallbacks. > Current compilers default to C++14. Very old compilers have no support for > C++11 or C++14. But compilers in between support it, but not by default. > This adds the feature tests to check for such support and enable it when > available. > The CMake C++ standard support is user-configurable by setting the > CMAKE_CXX_STANDARD setting. Autoconf doesn't provide any way to do this, so > the feature enabling isn't explicitly overridable. I'm not sure if that's > too problematic. The main compatibility concern might be if this causes an > ABI break with use of C++11/14 library features like the new string type. > However, we aren't making use of any of these features. The main change > would be the XMLCh type switch from uint16_t to char16_t. I'm not sure what > the Xerces policy for such changes has been in the past. Any thoughts? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2141) Enable C++11/14/17 with autoconf build
[ https://issues.apache.org/jira/browse/XERCESC-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2141: - Labels: autoconf build c++11 c++14 c++17 (was: autoconf build c++11 c++14) > Enable C++11/14/17 with autoconf build > -- > > Key: XERCESC-2141 > URL: https://issues.apache.org/jira/browse/XERCESC-2141 > Project: Xerces-C++ > Issue Type: Improvement > Components: Build >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Labels: autoconf, build, c++11, c++14, c++17 > Fix For: 3.3.0 > > Attachments: 0001-autoconf-Enable-C-14-or-C-11-when-available.patch > > > The CMake build will try to put the compiler in C++14 mode, falling back to > C++11 then C++98. The autoconf build doesn't do this, and the attached patch > makes the behaviour match so both build systems will use the same fallbacks. > Current compilers default to C++14. Very old compilers have no support for > C++11 or C++14. But compilers in between support it, but not by default. > This adds the feature tests to check for such support and enable it when > available. > The CMake C++ standard support is user-configurable by setting the > CMAKE_CXX_STANDARD setting. Autoconf doesn't provide any way to do this, so > the feature enabling isn't explicitly overridable. I'm not sure if that's > too problematic. The main compatibility concern might be if this causes an > ABI break with use of C++11/14 library features like the new string type. > However, we aren't making use of any of these features. The main change > would be the XMLCh type switch from uint16_t to char16_t. I'm not sure what > the Xerces policy for such changes has been in the past. Any thoughts? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2141) Enable C++11/14/17 with autoconf build and CMake build
[ https://issues.apache.org/jira/browse/XERCESC-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2141: - Summary: Enable C++11/14/17 with autoconf build and CMake build (was: Enable C++11/14/17 with autoconf build) > Enable C++11/14/17 with autoconf build and CMake build > -- > > Key: XERCESC-2141 > URL: https://issues.apache.org/jira/browse/XERCESC-2141 > Project: Xerces-C++ > Issue Type: Improvement > Components: Build >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Labels: autoconf, build, c++11, c++14, c++17 > Fix For: 3.3.0 > > Attachments: 0001-autoconf-Enable-C-14-or-C-11-when-available.patch > > > The CMake build will try to put the compiler in C++14 mode, falling back to > C++11 then C++98. The autoconf build doesn't do this, and the attached patch > makes the behaviour match so both build systems will use the same fallbacks. > Current compilers default to C++14. Very old compilers have no support for > C++11 or C++14. But compilers in between support it, but not by default. > This adds the feature tests to check for such support and enable it when > available. > The CMake C++ standard support is user-configurable by setting the > CMAKE_CXX_STANDARD setting. Autoconf doesn't provide any way to do this, so > the feature enabling isn't explicitly overridable. I'm not sure if that's > too problematic. The main compatibility concern might be if this causes an > ABI break with use of C++11/14 library features like the new string type. > However, we aren't making use of any of these features. The main change > would be the XMLCh type switch from uint16_t to char16_t. I'm not sure what > the Xerces policy for such changes has been in the past. Any thoughts? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2141) Enable C++11/14/17 with autoconf build
[ https://issues.apache.org/jira/browse/XERCESC-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2141: - Summary: Enable C++11/14/17 with autoconf build (was: Enable C++11/14 with autoconf build) > Enable C++11/14/17 with autoconf build > -- > > Key: XERCESC-2141 > URL: https://issues.apache.org/jira/browse/XERCESC-2141 > Project: Xerces-C++ > Issue Type: Improvement > Components: Build >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Labels: autoconf, build, c++11, c++14 > Fix For: 3.3.0 > > Attachments: 0001-autoconf-Enable-C-14-or-C-11-when-available.patch > > > The CMake build will try to put the compiler in C++14 mode, falling back to > C++11 then C++98. The autoconf build doesn't do this, and the attached patch > makes the behaviour match so both build systems will use the same fallbacks. > Current compilers default to C++14. Very old compilers have no support for > C++11 or C++14. But compilers in between support it, but not by default. > This adds the feature tests to check for such support and enable it when > available. > The CMake C++ standard support is user-configurable by setting the > CMAKE_CXX_STANDARD setting. Autoconf doesn't provide any way to do this, so > the feature enabling isn't explicitly overridable. I'm not sure if that's > too problematic. The main compatibility concern might be if this causes an > ABI break with use of C++11/14 library features like the new string type. > However, we aren't making use of any of these features. The main change > would be the XMLCh type switch from uint16_t to char16_t. I'm not sure what > the Xerces policy for such changes has been in the past. Any thoughts? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Assigned] (XERCESC-2141) Enable C++11/14 with autoconf build
[ https://issues.apache.org/jira/browse/XERCESC-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh reassigned XERCESC-2141: Assignee: Roger Leigh > Enable C++11/14 with autoconf build > --- > > Key: XERCESC-2141 > URL: https://issues.apache.org/jira/browse/XERCESC-2141 > Project: Xerces-C++ > Issue Type: Improvement > Components: Build >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Labels: autoconf, build, c++11, c++14 > Fix For: 3.3.0 > > Attachments: 0001-autoconf-Enable-C-14-or-C-11-when-available.patch > > > The CMake build will try to put the compiler in C++14 mode, falling back to > C++11 then C++98. The autoconf build doesn't do this, and the attached patch > makes the behaviour match so both build systems will use the same fallbacks. > Current compilers default to C++14. Very old compilers have no support for > C++11 or C++14. But compilers in between support it, but not by default. > This adds the feature tests to check for such support and enable it when > available. > The CMake C++ standard support is user-configurable by setting the > CMAKE_CXX_STANDARD setting. Autoconf doesn't provide any way to do this, so > the feature enabling isn't explicitly overridable. I'm not sure if that's > too problematic. The main compatibility concern might be if this causes an > ABI break with use of C++11/14 library features like the new string type. > However, we aren't making use of any of these features. The main change > would be the XMLCh type switch from uint16_t to char16_t. I'm not sure what > the Xerces policy for such changes has been in the past. Any thoughts? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2202) Update version of master branch to 3.3.0
Roger Leigh created XERCESC-2202: Summary: Update version of master branch to 3.3.0 Key: XERCESC-2202 URL: https://issues.apache.org/jira/browse/XERCESC-2202 Project: Xerces-C++ Issue Type: Bug Components: Miscellaneous Affects Versions: 3.3.0 Reporter: Roger Leigh Assignee: Roger Leigh Fix For: 3.3.0 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2201) Update Travis-CI image in use
Roger Leigh created XERCESC-2201: Summary: Update Travis-CI image in use Key: XERCESC-2201 URL: https://issues.apache.org/jira/browse/XERCESC-2201 Project: Xerces-C++ Issue Type: Bug Components: Miscellaneous Affects Versions: 3.3.0 Reporter: Roger Leigh Assignee: Roger Leigh Fix For: 3.3.0 Update image to use current image e.g. Ubuntu 20.04 LTS, which should see us supported for some time into the future. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2200) Update AppVeyor image in use
Roger Leigh created XERCESC-2200: Summary: Update AppVeyor image in use Key: XERCESC-2200 URL: https://issues.apache.org/jira/browse/XERCESC-2200 Project: Xerces-C++ Issue Type: Bug Components: Miscellaneous Affects Versions: 3.3.0 Reporter: Roger Leigh Assignee: Roger Leigh Fix For: 3.3.0 AppVeyor images haven't been upgraded for some time. Update to newer image with VS2019 or VS2017, and switch to vcpkg for ICU and CURL dependencies etc. which are now provided directly by vcpkg in the AppVeyor images. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2102) Documentation is not generatable on modern systems
[
https://issues.apache.org/jira/browse/XERCESC-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17119784#comment-17119784
]
Roger Leigh commented on XERCESC-2102:
--
[~scantor] You just put the documentation to publish on the "gh-pages" branch
and push it: see https://github.com/apache/xalan-c/tree/gh-pages for the live
site.
> 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
>Priority: Major
>
> 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 XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving cached document
> "sbk:/style/stylesheets/any2project.xsl" (17)
> [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl"
> [CachingParser] Serving
[jira] [Commented] (XERCESC-2102) Documentation is not generatable on modern systems
[
https://issues.apache.org/jira/browse/XERCESC-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17115559#comment-17115559
]
Roger Leigh commented on XERCESC-2102:
--
As a point of reference, I've recently done a full conversion of the Xalan-C++
documentation to Markdown, hosted on GitHub Pages:
[link|https://apache.github.io/xalan-c/].
The equivalent could be done for Xerces-C++. The sources are here:
https://github.com/apache/xalan-c/tree/master/docs
For Xalan, the website links are still all intact; they are all redirects to
the new pages. See https://xalan.staged.apache.org and any link under /xalan-c
(including the API reference) will be correctly redirected.
If that type of conversion would be agreeable, I'd be happy to repeat the
process for Xerces-C++.
> 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
>Priority: Major
>
> 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)
[jira] [Resolved] (XERCESC-2176) Incorrect symbolic links created for Linux static library and MacOS static and shared libraries
[
https://issues.apache.org/jira/browse/XERCESC-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roger Leigh resolved XERCESC-2176.
--
Fix Version/s: 3.3.0
Resolution: Fixed
> Incorrect symbolic links created for Linux static library and MacOS static
> and shared libraries
> ---
>
> Key: XERCESC-2176
> URL: https://issues.apache.org/jira/browse/XERCESC-2176
> Project: Xerces-C++
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.2.0, 3.2.1, 3.2.2
> Environment: Linux, MacOS
>Reporter: Brent Davis
>Assignee: Roger Leigh
>Priority: Minor
> Fix For: 3.2.3, 3.3.0
>
>
> We build Xerces-C++ for both the Linux and MacOS platforms, with both static
> and shared libraries. There are arguably some dubiously named symbolic links
> created by src/CMakeLists.txt. The symlinks are always named
> 'libxerces-c.so' regardless or library type, or use of the .dylib extension
> on MacOS.
> ||Platform||Library Type||Symbolic Link||Comment||
> |{color:#de350b}Linux{color}|{color:#de350b}static{color}|{color:#de350b}libxerces-c.so
> -> libxerces-c-3.2.a{color}|{color:#de350b}symbolic link should either be
> libxerces-c.a or not created{color}|
> |{color:#00875a}
> {color}|{color:#00875a}shared{color}|{color:#00875a}libxerces-c.so ->
> libxerces-c-3.2.so{color}|{color:#00875a}good{color}|
> |{color:#de350b}MacOS{color}|{color:#de350b}static{color}|{color:#de350b}libxerces-c.so
> -> libxerces-c-3.2.a{color}|{color:#de350b}symbolic link should either be
> libxerces-c.a or not created{color}|
> |{color:#de350b}
> {color}|{color:#de350b}shared{color}|{color:#de350b}libxerces-c.so ->
> libxerces-c-3.2.dylib{color}|{color:#de350b}symbolic link should best be
> named libxerces-c.dylib{color}|
> Curiously, the Microsoft _vcpkg_ folks just recently ran into the Linux
> static library portion of this issue and elected to not create the symlink in
> that case. See [[xerces-c] produces strange files in
> installed/x64-linux/lib|[https://github.com/microsoft/vcpkg/issues/7490]].
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2176) Incorrect symbolic links created for Linux static library and MacOS static and shared libraries
[
https://issues.apache.org/jira/browse/XERCESC-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17073687#comment-17073687
]
Roger Leigh commented on XERCESC-2176:
--
[~brentd] Please could you give one of the PRs a try and confirm if it
addresses the issue to your satisfaction?
Thanks, Roger
> Incorrect symbolic links created for Linux static library and MacOS static
> and shared libraries
> ---
>
> Key: XERCESC-2176
> URL: https://issues.apache.org/jira/browse/XERCESC-2176
> Project: Xerces-C++
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.2.0, 3.2.1, 3.2.2
> Environment: Linux, MacOS
>Reporter: Brent Davis
>Assignee: Roger Leigh
>Priority: Minor
> Fix For: 3.2.3
>
>
> We build Xerces-C++ for both the Linux and MacOS platforms, with both static
> and shared libraries. There are arguably some dubiously named symbolic links
> created by src/CMakeLists.txt. The symlinks are always named
> 'libxerces-c.so' regardless or library type, or use of the .dylib extension
> on MacOS.
> ||Platform||Library Type||Symbolic Link||Comment||
> |{color:#de350b}Linux{color}|{color:#de350b}static{color}|{color:#de350b}libxerces-c.so
> -> libxerces-c-3.2.a{color}|{color:#de350b}symbolic link should either be
> libxerces-c.a or not created{color}|
> |{color:#00875a}
> {color}|{color:#00875a}shared{color}|{color:#00875a}libxerces-c.so ->
> libxerces-c-3.2.so{color}|{color:#00875a}good{color}|
> |{color:#de350b}MacOS{color}|{color:#de350b}static{color}|{color:#de350b}libxerces-c.so
> -> libxerces-c-3.2.a{color}|{color:#de350b}symbolic link should either be
> libxerces-c.a or not created{color}|
> |{color:#de350b}
> {color}|{color:#de350b}shared{color}|{color:#de350b}libxerces-c.so ->
> libxerces-c-3.2.dylib{color}|{color:#de350b}symbolic link should best be
> named libxerces-c.dylib{color}|
> Curiously, the Microsoft _vcpkg_ folks just recently ran into the Linux
> static library portion of this issue and elected to not create the symlink in
> that case. See [[xerces-c] produces strange files in
> installed/x64-linux/lib|[https://github.com/microsoft/vcpkg/issues/7490]].
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2176) Incorrect symbolic links created for Linux static library and MacOS static and shared libraries
[
https://issues.apache.org/jira/browse/XERCESC-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17073686#comment-17073686
]
Roger Leigh commented on XERCESC-2176:
--
PRs opened for dev and 3.2: https://github.com/apache/xerces-c/pull/9 and
https://github.com/apache/xerces-c/pull/10
> Incorrect symbolic links created for Linux static library and MacOS static
> and shared libraries
> ---
>
> Key: XERCESC-2176
> URL: https://issues.apache.org/jira/browse/XERCESC-2176
> Project: Xerces-C++
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.2.0, 3.2.1, 3.2.2
> Environment: Linux, MacOS
>Reporter: Brent Davis
>Assignee: Roger Leigh
>Priority: Minor
> Fix For: 3.2.3
>
>
> We build Xerces-C++ for both the Linux and MacOS platforms, with both static
> and shared libraries. There are arguably some dubiously named symbolic links
> created by src/CMakeLists.txt. The symlinks are always named
> 'libxerces-c.so' regardless or library type, or use of the .dylib extension
> on MacOS.
> ||Platform||Library Type||Symbolic Link||Comment||
> |{color:#de350b}Linux{color}|{color:#de350b}static{color}|{color:#de350b}libxerces-c.so
> -> libxerces-c-3.2.a{color}|{color:#de350b}symbolic link should either be
> libxerces-c.a or not created{color}|
> |{color:#00875a}
> {color}|{color:#00875a}shared{color}|{color:#00875a}libxerces-c.so ->
> libxerces-c-3.2.so{color}|{color:#00875a}good{color}|
> |{color:#de350b}MacOS{color}|{color:#de350b}static{color}|{color:#de350b}libxerces-c.so
> -> libxerces-c-3.2.a{color}|{color:#de350b}symbolic link should either be
> libxerces-c.a or not created{color}|
> |{color:#de350b}
> {color}|{color:#de350b}shared{color}|{color:#de350b}libxerces-c.so ->
> libxerces-c-3.2.dylib{color}|{color:#de350b}symbolic link should best be
> named libxerces-c.dylib{color}|
> Curiously, the Microsoft _vcpkg_ folks just recently ran into the Linux
> static library portion of this issue and elected to not create the symlink in
> that case. See [[xerces-c] produces strange files in
> installed/x64-linux/lib|[https://github.com/microsoft/vcpkg/issues/7490]].
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2176) Incorrect symbolic links created for Linux static library and MacOS static and shared libraries
[
https://issues.apache.org/jira/browse/XERCESC-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17073671#comment-17073671
]
Roger Leigh commented on XERCESC-2176:
--
The CMake logic we have is buggy, and should only be applied to shared
libraries, not static. That aspect should be trivial to change.
The root cause of the problem is that we're trying to match the GNU libtool
versioning *exactly* for strict compatibility, and while CMake itself can
handle library VERSION and SONAME properties perfectly on all supported
platforms, the semantics and library names differ which would make the CMake
build of Xerces-C not be directly substitutable for the Autotools build.
libtool is pretty terrible, and it's SOVERSION versioning support is
nonsensical. Like many projects using libtool, Xerces-C is using libtool's
"-release" option to avoid the worst brokenness:
{noformat}
(libxerces_c_la_LDFLAGS = -release @INTERFACE_VERSION_D@)
{noformat}
which is a shorthand for "encode the release version into the library name as a
suffix", because the real SONAME versioning is so woeful. The behaviour
difference is this:
- libtool produces libxerces-c-3.2.so and a libxerces.so symlink. And also
libxerces-c.so.3 symlink (both useless and nonsensical since we never actually
set a SOVERSION)
- CMake (with VERSION property) produces libxerces-c.so.3.2 and a libxerces.so
symlink
What we're doing right now is making CMake generate "libxerces-c-3.2" as the
library name. But that makes CMake skip symlink generation because we've
avoided using any of the versioning options. So we're creating the symlink
manually. We don't bother with the libxerces-c.so.3 because it doesn't serve
any useful or meaningful purpose in the absence of proper SOVERSION usage.
> Incorrect symbolic links created for Linux static library and MacOS static
> and shared libraries
> ---
>
> Key: XERCESC-2176
> URL: https://issues.apache.org/jira/browse/XERCESC-2176
> Project: Xerces-C++
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.2.0, 3.2.1, 3.2.2
> Environment: Linux, MacOS
>Reporter: Brent Davis
>Assignee: Roger Leigh
>Priority: Minor
> Fix For: 3.2.3
>
>
> We build Xerces-C++ for both the Linux and MacOS platforms, with both static
> and shared libraries. There are arguably some dubiously named symbolic links
> created by src/CMakeLists.txt. The symlinks are always named
> 'libxerces-c.so' regardless or library type, or use of the .dylib extension
> on MacOS.
> ||Platform||Library Type||Symbolic Link||Comment||
> |{color:#de350b}Linux{color}|{color:#de350b}static{color}|{color:#de350b}libxerces-c.so
> -> libxerces-c-3.2.a{color}|{color:#de350b}symbolic link should either be
> libxerces-c.a or not created{color}|
> |{color:#00875a}
> {color}|{color:#00875a}shared{color}|{color:#00875a}libxerces-c.so ->
> libxerces-c-3.2.so{color}|{color:#00875a}good{color}|
> |{color:#de350b}MacOS{color}|{color:#de350b}static{color}|{color:#de350b}libxerces-c.so
> -> libxerces-c-3.2.a{color}|{color:#de350b}symbolic link should either be
> libxerces-c.a or not created{color}|
> |{color:#de350b}
> {color}|{color:#de350b}shared{color}|{color:#de350b}libxerces-c.so ->
> libxerces-c-3.2.dylib{color}|{color:#de350b}symbolic link should best be
> named libxerces-c.dylib{color}|
> Curiously, the Microsoft _vcpkg_ folks just recently ran into the Linux
> static library portion of this issue and elected to not create the symlink in
> that case. See [[xerces-c] produces strange files in
> installed/x64-linux/lib|[https://github.com/microsoft/vcpkg/issues/7490]].
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2190) deprecated GetVersionEx
[
https://issues.apache.org/jira/browse/XERCESC-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17073107#comment-17073107
]
Roger Leigh commented on XERCESC-2190:
--
Yes, I was surprised when I went to check on Server 2008 R2 in more detail.
It's not that long since I had to support it either.
For RHEL6, I used to use devtoolset-8 for development on this platform. It's
definitely a viable option for users who need to target it.
I'm certainly not suggesting deliberately ripping support for older platform
out just for the sake of it. But I do feel that given the development
constraints we are working under, it would be good to be realistic about what
is effectively supportable, and what is absolutely unsupportable, and there are
quite a few platforms which I do feel are not reasonable to support in any
capacity. I'd say Windows Vista and below fall in that category. Windows 7 is
hanging on by a thread but realistically I can't test on it any longer; I've
been forced onto Windows 10 and VS2017/VS2019, and Server 2016. AppVeyor can
be used to test on other compilers up to a point, but debugging and more
extensive testing aren't possible.
> deprecated GetVersionEx
> ---
>
> Key: XERCESC-2190
> URL: https://issues.apache.org/jira/browse/XERCESC-2190
> Project: Xerces-C++
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Aleksey Dobrunov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hello.
> *"GetVersionEx* may be altered or unavailable for releases after Windows 8.1.
> Instead, use the [Version Helper
> functions"|https://docs.microsoft.com/windows/desktop/SysInfo/version-helper-apis]
>
> [https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getversionexa]
> .
> {code:java}
> C:\Work\code\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(323):
> warning C4996: 'GetVersionExA': was declared deprecated
> C:\Program Files (x86)\Windows
> Kits\10\include\10.0.18362.0\um\sysinfoapi.h(387): note: see declaration of
> 'GetVersionExA'
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2177) invalid windows version check for `onXPOrLater`
[
https://issues.apache.org/jira/browse/XERCESC-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17073098#comment-17073098
]
Roger Leigh commented on XERCESC-2177:
--
As mentioned on XERCESC-2190 I think we would be better off deleting use of
this function entirely and assuming that we're on a recent enough Windows
platform. Since the affected versions are over two decades old and thoroughly
obsolete, and no supported development environment can target them, that's a
fairly safe assumption to make.
> invalid windows version check for `onXPOrLater`
> ---
>
> Key: XERCESC-2177
> URL: https://issues.apache.org/jira/browse/XERCESC-2177
> Project: Xerces-C++
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 3.2.0, 3.2.1, 3.2.2
> Environment: win10 x64
>Reporter: Vvv
>Assignee: Alberto Massari
>Priority: Minor
> Labels: beginner, easyfix, windows
> Fix For: 3.2.3
>
>
> in
> {{xerces-c-3.2.2\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp:324}}
>
> {{ if ((OSVer.dwPlatformId == VER_PLATFORM_WIN32_NT) &&}}
> {{ ((OSVer.dwMajorVersion == 5) && (OSVer.dwMinorVersion > 0)))}}
> {{ {}}
> {{ onXPOrLater = true;}}
> {{ }}}
> on win10 {{OSVer.dwMajorVersion = 6}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2190) deprecated GetVersionEx
[
https://issues.apache.org/jira/browse/XERCESC-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17073003#comment-17073003
]
Roger Leigh commented on XERCESC-2190:
--
I think that as a project we should have a clearly supported list of platforms
and compilers which we target, and be very clear about what isn't supported.
When it comes to Windows, I'd personally cut it off when Microsoft stop
supporting it completely. I've generally used their support page for this.
For example:
https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet By
this page, the final Windows 7 release went out of support in January, and also
so did the server version Windows 2008R2. This leaves us with Windows 8.1 and
10 to support.
On top of this, there are the corresponding Visual Studio versions which
support these releases. For these two major versions, that includes VS2013,
VS2015, VS2017 and VS2019. In other projects, I target a maximum of three
Visual Studio releases simply due to the logistics of testing and supporting
several versions. For Xerces-C, I'd suggest that as the maximum due to the
manpower available. That would give use a VS2015 baseline.
For 3.3, if that sounds reasonable, I'd like to make that official. Similarly,
making C++11 the minimum on all platforms would be something to consider, given
that at this point it's available almost universally.
> deprecated GetVersionEx
> ---
>
> Key: XERCESC-2190
> URL: https://issues.apache.org/jira/browse/XERCESC-2190
> Project: Xerces-C++
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Aleksey Dobrunov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hello.
> *"GetVersionEx* may be altered or unavailable for releases after Windows 8.1.
> Instead, use the [Version Helper
> functions"|https://docs.microsoft.com/windows/desktop/SysInfo/version-helper-apis]
>
> [https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getversionexa]
> .
> {code:java}
> C:\Work\code\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(323):
> warning C4996: 'GetVersionExA': was declared deprecated
> C:\Program Files (x86)\Windows
> Kits\10\include\10.0.18362.0\um\sysinfoapi.h(387): note: see declaration of
> 'GetVersionExA'
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2176) Incorrect symbolic links created for Linux static library and MacOS static and shared libraries
[
https://issues.apache.org/jira/browse/XERCESC-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17072988#comment-17072988
]
Roger Leigh commented on XERCESC-2176:
--
Sorry I've not had time to devote to this yet, I've had a very busy couple of
months.
> Incorrect symbolic links created for Linux static library and MacOS static
> and shared libraries
> ---
>
> Key: XERCESC-2176
> URL: https://issues.apache.org/jira/browse/XERCESC-2176
> Project: Xerces-C++
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.2.0, 3.2.1, 3.2.2
> Environment: Linux, MacOS
>Reporter: Brent Davis
>Assignee: Roger Leigh
>Priority: Minor
> Fix For: 3.2.3
>
>
> We build Xerces-C++ for both the Linux and MacOS platforms, with both static
> and shared libraries. There are arguably some dubiously named symbolic links
> created by src/CMakeLists.txt. The symlinks are always named
> 'libxerces-c.so' regardless or library type, or use of the .dylib extension
> on MacOS.
> ||Platform||Library Type||Symbolic Link||Comment||
> |{color:#de350b}Linux{color}|{color:#de350b}static{color}|{color:#de350b}libxerces-c.so
> -> libxerces-c-3.2.a{color}|{color:#de350b}symbolic link should either be
> libxerces-c.a or not created{color}|
> |{color:#00875a}
> {color}|{color:#00875a}shared{color}|{color:#00875a}libxerces-c.so ->
> libxerces-c-3.2.so{color}|{color:#00875a}good{color}|
> |{color:#de350b}MacOS{color}|{color:#de350b}static{color}|{color:#de350b}libxerces-c.so
> -> libxerces-c-3.2.a{color}|{color:#de350b}symbolic link should either be
> libxerces-c.a or not created{color}|
> |{color:#de350b}
> {color}|{color:#de350b}shared{color}|{color:#de350b}libxerces-c.so ->
> libxerces-c-3.2.dylib{color}|{color:#de350b}symbolic link should best be
> named libxerces-c.dylib{color}|
> Curiously, the Microsoft _vcpkg_ folks just recently ran into the Linux
> static library portion of this issue and elected to not create the symlink in
> that case. See [[xerces-c] produces strange files in
> installed/x64-linux/lib|[https://github.com/microsoft/vcpkg/issues/7490]].
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2190) deprecated GetVersionEx
[
https://issues.apache.org/jira/browse/XERCESC-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17072987#comment-17072987
]
Roger Leigh commented on XERCESC-2190:
--
I checked both call sites.
WindowsFileMgr.cpp: Used to check if on NT or not. Can be dropped entirely (I
doubt anyone cares about Windows 9x at this point)
Win32TransService: Used to check if on XP or later. Can be dropped entirely
(even XP is obsolete and unsupported at this point)
So both should be completely safe to drop. They are only needed for Win9x and
Win2000 respectively.
> deprecated GetVersionEx
> ---
>
> Key: XERCESC-2190
> URL: https://issues.apache.org/jira/browse/XERCESC-2190
> Project: Xerces-C++
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Aleksey Dobrunov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hello.
> *"GetVersionEx* may be altered or unavailable for releases after Windows 8.1.
> Instead, use the [Version Helper
> functions"|https://docs.microsoft.com/windows/desktop/SysInfo/version-helper-apis]
>
> [https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getversionexa]
> .
> {code:java}
> C:\Work\code\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(323):
> warning C4996: 'GetVersionExA': was declared deprecated
> C:\Program Files (x86)\Windows
> Kits\10\include\10.0.18362.0\um\sysinfoapi.h(387): note: see declaration of
> 'GetVersionExA'
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2163) XercesMessages_en_US.cat is installed to wrong directory
[
https://issues.apache.org/jira/browse/XERCESC-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052453#comment-17052453
]
Roger Leigh commented on XERCESC-2163:
--
[~candrews] With the switchover of Xerces-C to git, it looks like your PR got
lost when the mirror was switched over to the real repo. Please could you
reopen your PR against the new repository. Thanks!
> XercesMessages_en_US.cat is installed to wrong directory
>
>
> Key: XERCESC-2163
> URL: https://issues.apache.org/jira/browse/XERCESC-2163
> Project: Xerces-C++
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.2.0, 3.2.1, 3.2.2
>Reporter: Craig
>Assignee: Roger Leigh
>Priority: Major
> Labels: cmake
> Fix For: 3.2.3
>
>
> When building with the
> {code}-Dmessage-loader=iconv{code}
> cmake option, {{XercesMessages_en_US.cat}} is installed to:
> {{/usr/msg/}}
> It should be installed to:
> {{/usr/share/xerces-c/msg/}}
> which is what previous versions of Xerces-C did.
> This change breaks downstream consumers of Xerces-C, such as Xalan-C (which
> fails to build as it cannot find {{XercesMessages_en_US.cat}}).
> Originally reported at https://bugs.gentoo.org/673548
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2156) fix static linking with curl
[ https://issues.apache.org/jira/browse/XERCESC-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052450#comment-17052450 ] Roger Leigh commented on XERCESC-2156: -- The provided patch switches from the CMake FindCURL script to using pkg-config by default. I'm not sure that's the correct approach, but would be happy to discuss further. If FindCURL is not finding the static version of the CURL library, I think the best course of action would be to contribute the necessary fix for this module to CMake upstream and/or the CURL upstream if it's a CURL-provided config module. The patch as provided is using pkg-config by default and then falling back to FindCURL as a fallback. If we were to go with this approach, I think that we should be doing it the other way around and falling back to pkg-config, since FindCURL should be the canonical way to find it with CMake. > fix static linking with curl > > > Key: XERCESC-2156 > URL: https://issues.apache.org/jira/browse/XERCESC-2156 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.0, 3.2.1, 3.2.2 >Reporter: Fabrice Fontaine >Assignee: Roger Leigh >Priority: Minor > Fix For: 3.2.3 > > Attachments: 0001-fix-static-linking-with-curl.patch > > > When curl is statically built with openssl support, xerces needs to > link with openssl libraries so use pkg_check_modules to get any > needed dependencies > Fixes: > - > http://autobuild.buildroot.org/results/29ca90fff2c8e38f2edf7240eca3aa3fe7397c45 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2138) Xerces-C++ should use C++98 features and remove pre-Standard workarounds
[ https://issues.apache.org/jira/browse/XERCESC-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052445#comment-17052445 ] Roger Leigh commented on XERCESC-2138: -- What are the problems with a GitHub-based workflow specifically? Does GitBox proxy all this stuff to allow you to work without direct GitHub interaction? After switching over to git, it would be a great shame if we prevented more widespread community engagement with and access to the xerces codebase. Regarding 3.3, could we create a branch to allow new development in parallel with the stable 3.2 releases? While development would not necessarily be rapid or of great quantity, it would provide a place for development to take place without blocking it, or interfering with the stable branch. > Xerces-C++ should use C++98 features and remove pre-Standard workarounds > > > Key: XERCESC-2138 > URL: https://issues.apache.org/jira/browse/XERCESC-2138 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.0 >Reporter: Johnny Willemsen >Assignee: Roger Leigh >Priority: Trivial > Attachments: 0001-Make-XSConstants-a-namespace.patch, > 0002-Drop-XERCES_HAS_CPP_NAMESPACE-check.patch, > 0003-Drop-XERCES_STD_NAMESPACE-check.patch, > 0004-Drop-XERCES_NO_NATIVE_BOOL-check.patch, > 0005-Drop-XERCES_NEW_IOSTREAMS-check.patch, > 0006-Use-cstdlib-in-place-of-stdlib.h.patch, > 0007-Use-cstdio-in-place-of-stdio.h.patch, > 0008-Use-cstring-in-place-of-string.h.patch, > 0009-Remove-use-of-strings.h.patch, > 0010-Use-std-in-place-of-XERCES_STD_QUALIFIER.patch, > 0011-Drop-const-workarounds.patch, 0012-Drop-inline-workarounds.patch, > 0013-Drop-unused-volatile-workarounds.patch, > 0014-Replace-XERCES_CPP_NAMESPACE-macros-with-real-namesp.patch > > > When compiling xercesc-3.2.0 with mingw-64 gcc 4.9.3 on Windows we get a lot > of warnings, for example: > class xercesc_3_2::XSConstants' only defines private constructors and has no > friends > In file included from > C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/src/xercesc/framework/psvi/XSObject.hpp:26:0, > Gandalf_win10_x86_64_01(administrator@172.16.2.213) > [pkg_xercesc:windows-pkg-xercesc] from > C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/src/xercesc/framework/psvi/XSTypeDefinition.hpp:25, > Gandalf_win10_x86_64_01(administrator@172.16.2.213) > [pkg_xercesc:windows-pkg-xercesc] from > C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/src/xercesc/framework/psvi/XSSimpleTypeDefinition.hpp:25, > Gandalf_win10_x86_64_01(administrator@172.16.2.213) > [pkg_xercesc:windows-pkg-xercesc] from > C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/src/xercesc/validators/datatype/DatatypeValidator.hpp:32, > Gandalf_win10_x86_64_01(administrator@172.16.2.213) > [pkg_xercesc:windows-pkg-xercesc] from > C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/src/xercesc/framework/XMLAttr.hpp:28, > Gandalf_win10_x86_64_01(administrator@172.16.2.213) > [pkg_xercesc:windows-pkg-xercesc] from > C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/src/xercesc/framework/XMLValidator.hpp:25, > Gandalf_win10_x86_64_01(administrator@172.16.2.213) > [pkg_xercesc:windows-pkg-xercesc] from > C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/src/xercesc/sax2/SAX2XMLReader.hpp:27, > Gandalf_win10_x86_64_01(administrator@172.16.2.213) > [pkg_xercesc:windows-pkg-xercesc] from > C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/samples/src/SAX2Print/SAX2Print.cpp:28: > Gandalf_win10_x86_64_01(administrator@172.16.2.213) > [pkg_xercesc:windows-pkg-xercesc] > C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/src/xercesc/framework/psvi/XSConstants.hpp:56:24: > warning: 'class xercesc_3_2::XSConstants' only defines private constructors > and has no friends [-Wctor-dtor-privacy] > Gandalf_win10_x86_64_01(administrator@172.16.2.213) > [pkg_xercesc:windows-pkg-xercesc] class XMLPARSER_EXPORT XSConstants > Gandalf_win10_x86_64_01(administrator@172.16.2.213) > [pkg_xercesc:windows-pkg-xercesc] ^ -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands,
[jira] [Commented] (XERCESC-2194) Including Xerces_autoconf_config.hpp on Windows fails due to undefined ssize_t
[
https://issues.apache.org/jira/browse/XERCESC-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17052442#comment-17052442
]
Roger Leigh commented on XERCESC-2194:
--
Looking at https://cmake.org/cmake/help/v3.16/module/CheckTypeSize.html I agree
that HAVE_ should be fine. However, I'm curious as to why the existing
logic is not working for you. What is the value of SIZEOF_SSIZE_T if you print
it out? Both "" and 0 should evaluate to false. That's my understanding of
https://cmake.org/cmake/help/v3.0/command/if.html
HAVE_ was present back to CMake 3.0, so there are no compatibility
concerns to switching over. If you want to open a PR, I'll be happy to test.
> Including Xerces_autoconf_config.hpp on Windows fails due to undefined ssize_t
> --
>
> Key: XERCESC-2194
> URL: https://issues.apache.org/jira/browse/XERCESC-2194
> Project: Xerces-C++
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.2.2
>Reporter: Rasmus Thomsen
>Assignee: Scott Cantor
>Priority: Major
> Fix For: 3.2.3
>
>
> When including Xerces_autoconf_config.hpp on Windows the following error
> messages:
>
> {code:cpp}
> error C4430: Fehlender Typspezifizierer - int wird angenommen. Hinweis:
> "default-int" wird von C++ nicht unterstützt.
> error C2146: Syntaxfehler: Fehlendes ";" vor Bezeichner "XMLSSize_t"
> {code}
> (Sorry that these are in German - they translate to "Missing type specifier -
> assuming int" and "syntax error: missing ";" before identifier "XMLSSize_t")
> Apparently ssize_t is a POSIX extension and as such isn't available in MSVC
> (by default?)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2173) Application crashes with an error as "A wrong parameter was passed to a service or function"
[ https://issues.apache.org/jira/browse/XERCESC-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899133#comment-16899133 ] Roger Leigh commented on XERCESC-2173: -- The stack trace isn't too useful as is--it's not possible to see exactly where the error occurred. There are a few overloaded methods for loadMsg, and it's not clear which was at fault, or where. Please could you repeat with a Debug build? Looking at where the fault might be triggered, the most likely candidate is the transcoder. It might be worth trying an alternative one. The ICU, GNU iconv and MacOS transcoders all use a mutex. The fault is in locking a critical section, and it looks like you're using VS2013. I have a vague recollection that I've seen this issue before, and that it's a bug in the MSVC runtime. I'm certainly not seeing any problems of this nature with VS2015, VS2017 or VS2019. Part of the problem might be in creating/locking the mutex during the final stages of process shutdown. I hope that provides some pointers. > Application crashes with an error as "A wrong parameter was passed to a > service or function" > > > Key: XERCESC-2173 > URL: https://issues.apache.org/jira/browse/XERCESC-2173 > Project: Xerces-C++ > Issue Type: Bug > Components: Utilities >Affects Versions: 3.2.2 > Environment: Windows >Reporter: Samrin >Priority: Critical > Attachments: Crash_Call_Stack.png > > > Hi All, > We have an application which uses the latest xerces C++ 3.2.2 version. Upon > running the application when we press CTRL+C it crashes leading to error > message as "A wrong parameter was sent to service or function". This error > message is thrown in ntdll.dll file. > The call stack is attached for reference. Any help would be appreciated. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2174) xerces-c runs make check in linux, most of the results about Threadtest test case display fail.
[
https://issues.apache.org/jira/browse/XERCESC-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16898288#comment-16898288
]
Roger Leigh commented on XERCESC-2174:
--
It's not going to be clear what is going on here without a bit of investigation.
I would suggest starting by installing gdb in the container, and then running
the command specified in the shell script within gdb, then get a backtrace when
the segfault happens. This should show exactly where the segfault occurs.
All the Linux CI builds test building with Ubuntu in a docker image (trusty).
We should probably update it to use a newer version. But I don't see any
reason for it to fail in Docker or on Ubuntu; it should work on every version
without trouble.
> xerces-c runs make check in linux, most of the results about Threadtest test
> case display fail.
>
>
> Key: XERCESC-2174
> URL: https://issues.apache.org/jira/browse/XERCESC-2174
> Project: Xerces-C++
> Issue Type: Test
>Reporter: Smart Yang
>Priority: Minor
>
> Dear author，
> I have a question about Threadtest test
> When I ran the test case on Ubuntu 16.04.2, most of the Threadtest test cases
> failed. When I looked at test-suit.log, I found the error message is the
> same: “../scripts/run-test: line 8 : 121998 Segmentation fault (core dumped)
> "${top_builddir}/$cmd" "$@" $input > "$output" 2> "$output" ”
> I executed the use case in the docker Ubuntu 16.04.2 image, and the
> Threadtest test case passed.
> The reason why this Threadtest test case fails is caused by the test
> environment or other reasons?
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2172) There is an error in the parameters of the ThreadTtest8 script in Apache xerces-c++ XML's tests/script
[ https://issues.apache.org/jira/browse/XERCESC-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh resolved XERCESC-2172. -- Resolution: Fixed Fix Version/s: 3.2.3 > There is an error in the parameters of the ThreadTtest8 script in Apache > xerces-c++ XML's tests/script > -- > > Key: XERCESC-2172 > URL: https://issues.apache.org/jira/browse/XERCESC-2172 > Project: Xerces-C++ > Issue Type: Bug > Components: Samples/Tests >Affects Versions: 3.2.2 >Reporter: Smart Yang >Assignee: Roger Leigh >Priority: Minor > Fix For: 3.2.3 > > > Dear Author; > I found that the parameter of the ThreadTtest8 script in the 3.6.2 > version of Apache xerces-c++ XML's tests/script has an error: the parameter > following run_test is "ThreadTtest8 " and not "ThreadTtest9 ". What do you > think？ -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Assigned] (XERCESC-2172) There is an error in the parameters of the ThreadTtest8 script in Apache xerces-c++ XML's tests/script
[ https://issues.apache.org/jira/browse/XERCESC-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh reassigned XERCESC-2172: Assignee: Roger Leigh > There is an error in the parameters of the ThreadTtest8 script in Apache > xerces-c++ XML's tests/script > -- > > Key: XERCESC-2172 > URL: https://issues.apache.org/jira/browse/XERCESC-2172 > Project: Xerces-C++ > Issue Type: Bug > Components: Samples/Tests >Affects Versions: 3.2.2 >Reporter: Smart Yang >Assignee: Roger Leigh >Priority: Minor > > Dear Author; > I found that the parameter of the ThreadTtest8 script in the 3.6.2 > version of Apache xerces-c++ XML's tests/script has an error: the parameter > following run_test is "ThreadTtest8 " and not "ThreadTtest9 ". What do you > think？ -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2172) There is an error in the parameters of the ThreadTtest8 script in Apache xerces-c++ XML's tests/script
[ https://issues.apache.org/jira/browse/XERCESC-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895584#comment-16895584 ] Roger Leigh commented on XERCESC-2172: -- This is correct. However, it has no practical impact upon the tests, being largely cosmetic. It might possibly affect parallel test execution. Fixed in SVN revision 1863969. > There is an error in the parameters of the ThreadTtest8 script in Apache > xerces-c++ XML's tests/script > -- > > Key: XERCESC-2172 > URL: https://issues.apache.org/jira/browse/XERCESC-2172 > Project: Xerces-C++ > Issue Type: Bug > Components: Samples/Tests >Affects Versions: 3.2.2 >Reporter: Smart Yang >Priority: Minor > > Dear Author; > I found that the parameter of the ThreadTtest8 script in the 3.6.2 > version of Apache xerces-c++ XML's tests/script has an error: the parameter > following run_test is "ThreadTtest8 " and not "ThreadTtest9 ". What do you > think？ -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2170) How to build 32bit xerces-c project on redhat8 64 OS
[ https://issues.apache.org/jira/browse/XERCESC-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16883267#comment-16883267 ] Roger Leigh commented on XERCESC-2170: -- Search for "redhat gcc 32-bit compile" and you'll find a number of suggestions about what to do. All the library dependencies will need to be available as 32-bit versions, and you'll need to use "-m32" or equivalent in CXXFLAGS to build as 32-bit. > How to build 32bit xerces-c project on redhat8 64 OS > - > > Key: XERCESC-2170 > URL: https://issues.apache.org/jira/browse/XERCESC-2170 > Project: Xerces-C++ > Issue Type: Wish >Reporter: le luo >Priority: Major > > Hello,Admin > As title, > I want to use xerces-c to do some test on redhat 8 OS. I can build 64 bit > xerces-c successful but can’t build 32 bit. Can you help tell me how to build > 32bit xerces-c project on redhat OS? > > Thanks your support > > Thanks -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2165) StdMutexMgr not working properly on VS2013 / Windows 7
[ https://issues.apache.org/jira/browse/XERCESC-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16747920#comment-16747920 ] Roger Leigh commented on XERCESC-2165: -- If you aren't supposed to acquire a lock during DllMain, then isn't this a problem in the OpenDSS library due to how it's using Xerces-C++? I'm not sure why C++11 mutexes would be any different than the original Windows implementation, unless there's an implementation defect in VS2013's runtime. Both should end up calling Enter/LeaveCriticalSection. Is it possible to get a stack trace with the msvcr120d symbols? Are they installed as the appropriate PDB? Regarding the release notes, it was ticket XERCESC-2140 which should have been closed to include. I've done so now. This can certainly be documented as a known issue. It's certainly the case that the CI testing is currently only done for VS2015, with VS2013 and earlier left untested. And we should probably add VS2017. I would not be averse to testing more Visual Studio versions if someone is willing to support them, but I don't personally have the time to dedicate to it. Kind regards, Roger > StdMutexMgr not working properly on VS2013 / Windows 7 > -- > > Key: XERCESC-2165 > URL: https://issues.apache.org/jira/browse/XERCESC-2165 > Project: Xerces-C++ > Issue Type: Bug > Components: Utilities >Affects Versions: 3.2.2 >Reporter: Andreas Kleber >Priority: Minor > Attachments: xerces-hang.png > > > I am building a dynamic library which statically links OpenDSS, which > statically links ACE which statically links xerces-c with Visual Studio 2013. > When I run my application on Windows 7 the loading of my dll hands during > static initialization in StdMutexManager::lock(). See attached screenshot. > On windows 10 the same binaries work as expected. > I am building xerces 3.2.2 with default parameters as static library with > VS2013. During my investigation I found that xerces 3.2.1 works as well as > specifying the WindowsMutexMgr during configure, because, well, StdMutexMgr > was introduced in 3.2.2. Btw, this introduction of a new default Mutex > Manager (at least default in my environment) is not mentioned in the release > notes. Whould have helped me a lot > In my environment all test pass on Windows 7 with StdMutexMgr. > Additional note: > [Microsoft|[https://docs.microsoft.com/en-us/windows/desktop/dlls/dynamic-link-library-best-practices]] > recommends not to acquire syncronization during dllmain. > As Windows 7 and VS 2013 are old and a workaround exists, this issue here is > intended as "known issue". -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2140) Add MutexMgr for C++11 mutex implementation
[ https://issues.apache.org/jira/browse/XERCESC-2140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh resolved XERCESC-2140. -- Resolution: Fixed Fix Version/s: 3.2.2 Should have been closed for 3.2.2. > Add MutexMgr for C++11 mutex implementation > --- > > Key: XERCESC-2140 > URL: https://issues.apache.org/jira/browse/XERCESC-2140 > Project: Xerces-C++ > Issue Type: Improvement > Components: Utilities >Affects Versions: 3.2.1 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Fix For: 3.2.2 > > Attachments: 0001-StdMutexMgr-Add-C-11-mutex-manager.patch > > > Xalan currently supports two mutex managers: POSIX and Windows (and > NoThreads, which doesn't really count). With the advent of C++11, it's no > longer necessary to use platform-specific threading facilities, since it's > built directly into the standard library. The attached patch adds a > StdMutexMgr which uses a C++11 mutex, and will work on Unix or Windows > systems with a sufficiently new compiler. thread/mutex were implemented > years ago, so all recent and not so recent systems should support it. For > those that don't, it will fall back to the POSIX/Windows managers and behave > like before. > > Options have been added to manually select the desired manager as for other > options for both cmake and autoconf (standard/posix/windows/nothreads). > Documented in more detail on the build page. > > It's tested on Linux/MacOS X/Windows with a variety of manager combinations, > and all looks fine so far. Any testing/comments much appreciated. It's a > compatible addition, so could go into 3.2.2 if that's acceptable, otherwise > could wait for later. > > Looking at all of the manager implementations, one key defect (likely > intentional design), is that there is zero exception safety. No currently > held mutex will be released if an exception gets thrown. That could be > prevented by moving to using C++11 threading entirely, and using > std::lock_guard, which will automatically release locks on unwind. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2162) ThreadTest freezes with Intel 17.0.5.239 and 18.0.1.163
[ https://issues.apache.org/jira/browse/XERCESC-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16719457#comment-16719457 ] Roger Leigh commented on XERCESC-2162: -- I'm unsure why volatile would be a needed qualifier on these specific variables. They shouldn't be optimised out, irrespective of whether volatile is added or not. fHeartBeat is intrinsically racy from what I can see; it's modified by both the main thread and the corresponding worker, and read in the main thread, but it's only used for some cosmetic reporting symbols as far as I can see. Moreover, we always run the thread tests with -quiet, so "if (gRunInfo.quiet == false..." on 1306 should always be false. fHeartBeat should be written once by the worker for each pass and never read. fInProgress is written in the worker and checked in the main thread at termination; should be safe given how it's used with or without volatile. I can see this deadlocking if a worker terminates early; it will never be reset back to false. fParses isn't actually used except for some trivial reporting; shouldn't be optimised out though fThreadNum is set once in the main thread and read by the worker, should be safe Are all four of these structure members definitely optimised out? Can you put a breakpoint in one of the workers and check each member at e.g. thInfo at line 1077 and 1150 for a few passes. I'm suspicious that the volatile qualifiers are hiding some deeper problem. It shouldn't be required for multi-threaded code, and neither GCC, Clang nor MSVC are optimising anything away. The compiler doesn't have sufficient information to elide these members as far as I can see. They are being passed by pointer to the thread main for each worker, and that should surely be a barrier to optimisation; the compiler should not be able to determine that it's not modified at this point, and that should kill any elision. At least, that's my take on it, but I could certainly be wrong. The 21 second timeout is because the test is run with "-time 20" and there's a final 1 second delay while the threads terminate. This is adjustable in the test configuration. > ThreadTest freezes with Intel 17.0.5.239 and 18.0.1.163 > --- > > Key: XERCESC-2162 > URL: https://issues.apache.org/jira/browse/XERCESC-2162 > Project: Xerces-C++ > Issue Type: Bug > Components: Samples/Tests >Affects Versions: 3.2.2 > Environment: cat /etc/redhat-release > Red Hat Enterprise Linux Server release 7.6 (Maipo) > uname -a > Linux tfe10 3.10.0-957.el7.x86_64 #1 SMP Thu Oct 4 20:48:51 UTC 2018 x86_64 > x86_64 x86_64 GNU/Linux > Two versions of the Intel compiler suite were tried: > icpc --version > icpc (ICC) 17.0.5 20170817 > Copyright (C) 1985-2017 Intel Corporation. All rights reserved. > icc --version > icc (ICC) 17.0.5 20170817 > Copyright (C) 1985-2017 Intel Corporation. All rights reserved. > icpc --version > icpc (ICC) 18.0.1 20171018 > Copyright (C) 1985-2017 Intel Corporation. All rights reserved. > icc --version > icc (ICC) 18.0.1 20171018 > Copyright (C) 1985-2017 Intel Corporation. All rights reserved. >Reporter: Sam Trahan >Priority: Major > > The ThreadTest1 hangs forever when Xerces-C 3.2.2 is compiled using the Intel > compiler versions 17.0.5.239 or 18.0.1.163. Running ThreadTest1 directly in > gdb reveals that all ten threads exit, and main() is stuck in a wait loop > calling sleep() forever. > export CXX=icpc > export CFLAGS='-fp-model precise' > export CXXFLAGS='-fp-model precise' > export CC=icc > export CPP="icc -E" > export CXXCPP="icpc -E" > ./configure --prefix=/some/path > make > make check > Changing the CXXFLAGS to this does not help: > export CXXFLAGS='-fp-model precise -std=c++11' > The last bit of output from "make check:" > make[3]: Entering directory `/a-very-long-path/.../tests' > PASS: scripts/DOMTest > PASS: scripts/DOMMemTest > PASS: scripts/RangeTest > PASS: scripts/DOMTraversalTest > XFAIL: scripts/XSerializerTest > PASS: scripts/XSerializerTest1 > PASS: scripts/XSerializerTest2 > PASS: scripts/XSerializerTest3 > PASS: scripts/XSerializerTest4 > PASS: scripts/XSerializerTest5 > PASS: scripts/XSValueTest > XFAIL: scripts/InitTermTest > PASS: scripts/InitTermTest1 > PASS: scripts/InitTermTest2 > PASS: scripts/InitTermTest3 > XFAIL: scripts/ThreadTest > The test hangs at that XFAIL: line. The "ps" command reveals ThreadTest1 is > running: > /a-very-long-path/.../tests/.libs/lt-ThreadTest -parser=sax -v=never -quiet > -threads 10 -time 20 personal.xml -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2162) ThreadTest freezes with Intel 17.0.5.239 and 18.0.1.163
[ https://issues.apache.org/jira/browse/XERCESC-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16718063#comment-16718063 ] Roger Leigh commented on XERCESC-2162: -- If you compile with the icc equivalent of "-g3", could you post the full stacktrace when it freezes so that we can see exactly where it's stuck? I wouldn't expect any significant difference between "standard" and "posix" because it's all ultimately pthreads underneath. But Xerces is using a somewhat indirect abstraction via the MutexManager, rather than the RAII-style you get with C++11 direct mutex locking. (Were we to require C++11, we could drop the MutexManager entirely and use C++11 threads and mutexes directly without this abstraction,) > ThreadTest freezes with Intel 17.0.5.239 and 18.0.1.163 > --- > > Key: XERCESC-2162 > URL: https://issues.apache.org/jira/browse/XERCESC-2162 > Project: Xerces-C++ > Issue Type: Bug > Components: Samples/Tests >Affects Versions: 3.2.2 > Environment: cat /etc/redhat-release > Red Hat Enterprise Linux Server release 7.6 (Maipo) > uname -a > Linux tfe10 3.10.0-957.el7.x86_64 #1 SMP Thu Oct 4 20:48:51 UTC 2018 x86_64 > x86_64 x86_64 GNU/Linux > Two versions of the Intel compiler suite were tried: > icpc --version > icpc (ICC) 17.0.5 20170817 > Copyright (C) 1985-2017 Intel Corporation. All rights reserved. > icc --version > icc (ICC) 17.0.5 20170817 > Copyright (C) 1985-2017 Intel Corporation. All rights reserved. > icpc --version > icpc (ICC) 18.0.1 20171018 > Copyright (C) 1985-2017 Intel Corporation. All rights reserved. > icc --version > icc (ICC) 18.0.1 20171018 > Copyright (C) 1985-2017 Intel Corporation. All rights reserved. >Reporter: Sam Trahan >Priority: Major > > The ThreadTest1 hangs forever when Xerces-C 3.2.2 is compiled using the Intel > compiler versions 17.0.5.239 or 18.0.1.163. Running ThreadTest1 directly in > gdb reveals that all ten threads exit, and main() is stuck in a wait loop > calling sleep() forever. > export CXX=icpc > export CFLAGS='-fp-model precise' > export CXXFLAGS='-fp-model precise' > export CC=icc > export CPP="icc -E" > export CXXCPP="icpc -E" > ./configure --prefix=/some/path > make > make check > Changing the CXXFLAGS to this does not help: > export CXXFLAGS='-fp-model precise -std=c++11' > The last bit of output from "make check:" > make[3]: Entering directory `/a-very-long-path/.../tests' > PASS: scripts/DOMTest > PASS: scripts/DOMMemTest > PASS: scripts/RangeTest > PASS: scripts/DOMTraversalTest > XFAIL: scripts/XSerializerTest > PASS: scripts/XSerializerTest1 > PASS: scripts/XSerializerTest2 > PASS: scripts/XSerializerTest3 > PASS: scripts/XSerializerTest4 > PASS: scripts/XSerializerTest5 > PASS: scripts/XSValueTest > XFAIL: scripts/InitTermTest > PASS: scripts/InitTermTest1 > PASS: scripts/InitTermTest2 > PASS: scripts/InitTermTest3 > XFAIL: scripts/ThreadTest > The test hangs at that XFAIL: line. The "ps" command reveals ThreadTest1 is > running: > /a-very-long-path/.../tests/.libs/lt-ThreadTest -parser=sax -v=never -quiet > -threads 10 -time 20 personal.xml -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2162) ThreadTest freezes with Intel 17.0.5.239 and 18.0.1.163
[ https://issues.apache.org/jira/browse/XERCESC-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16717529#comment-16717529 ] Roger Leigh commented on XERCESC-2162: -- Please could you try building with CMake with and without C++11 standard threads, rather than with the autoconf build. Use -Dmutex-manager=standard|posix as documented in the build instructions. This might do a better job of passing the appropriate options when compiling and linking, or doing icc-specific configuration. I haven't tried icc myself though, so I can't guarantee this will work. Thanks, Roger > ThreadTest freezes with Intel 17.0.5.239 and 18.0.1.163 > --- > > Key: XERCESC-2162 > URL: https://issues.apache.org/jira/browse/XERCESC-2162 > Project: Xerces-C++ > Issue Type: Bug > Components: Samples/Tests >Affects Versions: 3.2.2 > Environment: cat /etc/redhat-release > Red Hat Enterprise Linux Server release 7.6 (Maipo) > uname -a > Linux tfe10 3.10.0-957.el7.x86_64 #1 SMP Thu Oct 4 20:48:51 UTC 2018 x86_64 > x86_64 x86_64 GNU/Linux > Two versions of the Intel compiler suite were tried: > icpc --version > icpc (ICC) 17.0.5 20170817 > Copyright (C) 1985-2017 Intel Corporation. All rights reserved. > icc --version > icc (ICC) 17.0.5 20170817 > Copyright (C) 1985-2017 Intel Corporation. All rights reserved. > icpc --version > icpc (ICC) 18.0.1 20171018 > Copyright (C) 1985-2017 Intel Corporation. All rights reserved. > icc --version > icc (ICC) 18.0.1 20171018 > Copyright (C) 1985-2017 Intel Corporation. All rights reserved. >Reporter: Sam Trahan >Priority: Major > > The ThreadTest1 hangs forever when Xerces-C 3.2.2 is compiled using the Intel > compiler versions 17.0.5.239 or 18.0.1.163. Running ThreadTest1 directly in > gdb reveals that all ten threads exit, and main() is stuck in a wait loop > calling sleep() forever. > export CXX=icpc > export CFLAGS='-fp-model precise' > export CXXFLAGS='-fp-model precise' > export CC=icc > export CPP="icc -E" > export CXXCPP="icpc -E" > ./configure --prefix=/some/path > make > make check > Changing the CXXFLAGS to this does not help: > export CXXFLAGS='-fp-model precise -std=c++11' > The last bit of output from "make check:" > make[3]: Entering directory `/a-very-long-path/.../tests' > PASS: scripts/DOMTest > PASS: scripts/DOMMemTest > PASS: scripts/RangeTest > PASS: scripts/DOMTraversalTest > XFAIL: scripts/XSerializerTest > PASS: scripts/XSerializerTest1 > PASS: scripts/XSerializerTest2 > PASS: scripts/XSerializerTest3 > PASS: scripts/XSerializerTest4 > PASS: scripts/XSerializerTest5 > PASS: scripts/XSValueTest > XFAIL: scripts/InitTermTest > PASS: scripts/InitTermTest1 > PASS: scripts/InitTermTest2 > PASS: scripts/InitTermTest3 > XFAIL: scripts/ThreadTest > The test hangs at that XFAIL: line. The "ps" command reveals ThreadTest1 is > running: > /a-very-long-path/.../tests/.libs/lt-ThreadTest -parser=sax -v=never -quiet > -threads 10 -time 20 personal.xml -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2159) Xerces fails to build with VS 2015 due to deprecated timezone symbol
[ https://issues.apache.org/jira/browse/XERCESC-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16688384#comment-16688384 ] Roger Leigh commented on XERCESC-2159: -- It's building with VS2015 and VS2017 for me. Are you using additional compiler options to disable deprecated features? Or are there feature macros to expose it (looks like _XOPEN_SOURCE is used on Linux according to timezone(3))? > Xerces fails to build with VS 2015 due to deprecated timezone symbol > > > Key: XERCESC-2159 > URL: https://issues.apache.org/jira/browse/XERCESC-2159 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.2 >Reporter: Philip Armstrong >Priority: Major > Attachments: 0001-Fix-timezone-error-with-VS-2015.patch > > > timezone was deprecated in VS 2013 and removed in VS 2015. > The attached patch fixes the > problem.[^0001-Fix-timezone-error-with-VS-2015.patch] -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2088) Bad casting from DOMTextImpl to DOMElementImpl
[
https://issues.apache.org/jira/browse/XERCESC-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16683516#comment-16683516
]
Roger Leigh commented on XERCESC-2088:
--
It might be not possible to add an attachment because this particular issue has
been closed. Please could you open a new one for this request. Thanks.
> Bad casting from DOMTextImpl to DOMElementImpl
> --
>
> Key: XERCESC-2088
> URL: https://issues.apache.org/jira/browse/XERCESC-2088
> Project: Xerces-C++
> Issue Type: Bug
> Components: DOM
>Affects Versions: 3.1.1, 3.1.2, 3.1.3, 3.1.4
> Environment: ubuntu 16.04 LTS, Intel(R) Core(TM) i7-6700 CPU @
> 3.40GHz, 16GB
>Reporter: Yuseok Jeon
>Assignee: Scott Cantor
>Priority: Major
> Fix For: 3.2.0
>
> Attachments: Actual_result.txt, DOMNodeBase.hpp, casting.patch,
> relationship_tree.jpeg
>
>
> Hi all,
> Our recently developed type confusion detection tool reports a type_confusion
> error in the "xercesc/dom/imple/DOMCasts.hpp"
> xercesc/dom/imple/DOMCasts.hpp, line 146
> static inline DOMNodeImpl *castToNodeImpl(const DOMNode *p)
> {
> DOMElementImpl *pE = (DOMElementImpl *)p;
> return &(pE->fNode);
> }
> p is pointing to the object allocated as DOMTextImpl, and it is casted into
> DOMElementImpl. However, since DOMElementImpl is not a subobject of
> DOMTextImpl, it is violating C++ standard rules 5.2.9/11 (down casting is
> undefined if the object that the pointer to be casted points to is not a
> suboject of down casting type) and causes undefined behaviors.
> There are similar type-confusion cases as below links.
> - (libstdc++) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60734
> - (Firefox) https://bugzilla.mozilla.org/show_bug.cgi?id=1074280
> I attached a actual type confusion report and object relationship
> information.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2088) Bad casting from DOMTextImpl to DOMElementImpl
[
https://issues.apache.org/jira/browse/XERCESC-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682457#comment-16682457
]
Roger Leigh commented on XERCESC-2088:
--
[~phila] It would certainly be useful to see how you implemented this without
RTTI. I'm unsure how many Xerces-C++ users rely no no-rtti, is anyone else
requiring this?
There are other approaches which could also be considered such as std::variant
for "external polymorphism" (or equivalent implementations).
> Bad casting from DOMTextImpl to DOMElementImpl
> --
>
> Key: XERCESC-2088
> URL: https://issues.apache.org/jira/browse/XERCESC-2088
> Project: Xerces-C++
> Issue Type: Bug
> Components: DOM
>Affects Versions: 3.1.1, 3.1.2, 3.1.3, 3.1.4
> Environment: ubuntu 16.04 LTS, Intel(R) Core(TM) i7-6700 CPU @
> 3.40GHz, 16GB
>Reporter: Yuseok Jeon
>Assignee: Scott Cantor
>Priority: Major
> Fix For: 3.2.0
>
> Attachments: Actual_result.txt, DOMNodeBase.hpp, casting.patch,
> relationship_tree.jpeg
>
>
> Hi all,
> Our recently developed type confusion detection tool reports a type_confusion
> error in the "xercesc/dom/imple/DOMCasts.hpp"
> xercesc/dom/imple/DOMCasts.hpp, line 146
> static inline DOMNodeImpl *castToNodeImpl(const DOMNode *p)
> {
> DOMElementImpl *pE = (DOMElementImpl *)p;
> return &(pE->fNode);
> }
> p is pointing to the object allocated as DOMTextImpl, and it is casted into
> DOMElementImpl. However, since DOMElementImpl is not a subobject of
> DOMTextImpl, it is violating C++ standard rules 5.2.9/11 (down casting is
> undefined if the object that the pointer to be casted points to is not a
> suboject of down casting type) and causes undefined behaviors.
> There are similar type-confusion cases as below links.
> - (libstdc++) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60734
> - (Firefox) https://bugzilla.mozilla.org/show_bug.cgi?id=1074280
> I attached a actual type confusion report and object relationship
> information.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2088) Bad casting from DOMTextImpl to DOMElementImpl
[
https://issues.apache.org/jira/browse/XERCESC-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16680450#comment-16680450
]
Roger Leigh commented on XERCESC-2088:
--
I have removed the no-RTTI comments in r1846201.
[~canto...@osu.edu] What's the process for updating the website. Does it
require rolling a new release, or can this change be cherry-picked onto the
website branch?
> Bad casting from DOMTextImpl to DOMElementImpl
> --
>
> Key: XERCESC-2088
> URL: https://issues.apache.org/jira/browse/XERCESC-2088
> Project: Xerces-C++
> Issue Type: Bug
> Components: DOM
>Affects Versions: 3.1.1, 3.1.2, 3.1.3, 3.1.4
> Environment: ubuntu 16.04 LTS, Intel(R) Core(TM) i7-6700 CPU @
> 3.40GHz, 16GB
>Reporter: Yuseok Jeon
>Assignee: Scott Cantor
>Priority: Major
> Fix For: 3.2.0
>
> Attachments: Actual_result.txt, DOMNodeBase.hpp, casting.patch,
> relationship_tree.jpeg
>
>
> Hi all,
> Our recently developed type confusion detection tool reports a type_confusion
> error in the "xercesc/dom/imple/DOMCasts.hpp"
> xercesc/dom/imple/DOMCasts.hpp, line 146
> static inline DOMNodeImpl *castToNodeImpl(const DOMNode *p)
> {
> DOMElementImpl *pE = (DOMElementImpl *)p;
> return &(pE->fNode);
> }
> p is pointing to the object allocated as DOMTextImpl, and it is casted into
> DOMElementImpl. However, since DOMElementImpl is not a subobject of
> DOMTextImpl, it is violating C++ standard rules 5.2.9/11 (down casting is
> undefined if the object that the pointer to be casted points to is not a
> suboject of down casting type) and causes undefined behaviors.
> There are similar type-confusion cases as below links.
> - (libstdc++) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60734
> - (Firefox) https://bugzilla.mozilla.org/show_bug.cgi?id=1074280
> I attached a actual type confusion report and object relationship
> information.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Closed] (XERCESC-2155) fix build without pthread
[ https://issues.apache.org/jira/browse/XERCESC-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh closed XERCESC-2155. Resolution: Fixed Assignee: Roger Leigh Fix Version/s: 3.2.3 Fixed in SVN r1843653. Thanks for double-checking that this works. Your patch was fine by the way, but the revised patch matched the behaviour of the other option selection logic used in Xerces-C++. Thanks again, Roger > fix build without pthread > - > > Key: XERCESC-2155 > URL: https://issues.apache.org/jira/browse/XERCESC-2155 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.2 >Reporter: Fabrice Fontaine >Assignee: Roger Leigh >Priority: Minor > Fix For: 3.2.3 > > Attachments: > 0001-cmake-XercesMutexMgrSelection-Allow-nothreads-as-a-d.patch, > 0001-fix-build-without-pthread.patch > > > If threads is set to OFF, do not fail when pthreads is not available (see > attached patch) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2155) fix build without pthread
[ https://issues.apache.org/jira/browse/XERCESC-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16647728#comment-16647728 ] Roger Leigh commented on XERCESC-2155: -- Dear Fabrice, Thanks for the bug report and patch. Please could you try the alternative patch I've attached here, which is a bit simpler (it allows FindThreads to fail, and adjusts the threads option default accordingly). Thanks, Roger > fix build without pthread > - > > Key: XERCESC-2155 > URL: https://issues.apache.org/jira/browse/XERCESC-2155 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.2 >Reporter: Fabrice Fontaine >Priority: Minor > Attachments: > 0001-cmake-XercesMutexMgrSelection-Allow-nothreads-as-a-d.patch, > 0001-fix-build-without-pthread.patch > > > If threads is set to OFF, do not fail when pthreads is not available (see > attached patch) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2155) fix build without pthread
[ https://issues.apache.org/jira/browse/XERCESC-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2155: - Attachment: 0001-cmake-XercesMutexMgrSelection-Allow-nothreads-as-a-d.patch > fix build without pthread > - > > Key: XERCESC-2155 > URL: https://issues.apache.org/jira/browse/XERCESC-2155 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.2 >Reporter: Fabrice Fontaine >Priority: Minor > Attachments: > 0001-cmake-XercesMutexMgrSelection-Allow-nothreads-as-a-d.patch, > 0001-fix-build-without-pthread.patch > > > If threads is set to OFF, do not fail when pthreads is not available (see > attached patch) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2154) "terminate called after throwing an instance of 'xercesc_3_2::XMLErrs::Codes'" crash on Solaris x86 with invalid xml input (c++11)
[ https://issues.apache.org/jira/browse/XERCESC-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638288#comment-16638288 ] Roger Leigh commented on XERCESC-2154: -- Is the problem specific to C++11 or does the problem also occur with C++98? I don't think that the standard version should affect exception handling, but it might be worth checking. While your LD_LIBRARY_PATH and ldd output show it to be using the libgcc_s and libstdc++ from _/opt/developerstudio12.6_ I'm still a bit suspicious that somehow there might be a version mismatch here. It might be worth asking Oracle developer studio support, or on the GCC mailing list, since this is likely to be somewhat subtle and I don't personally have any recent Solaris expertise to draw upon. Given it looks like a low level problem in the C++/C runtime itself, I don't think there's a fault in Xerces-C++ here, unless there's something we can add to the Autoconf logic for Solaris. > "terminate called after throwing an instance of > 'xercesc_3_2::XMLErrs::Codes'" crash on Solaris x86 with invalid xml input > (c++11) > -- > > Key: XERCESC-2154 > URL: https://issues.apache.org/jira/browse/XERCESC-2154 > Project: Xerces-C++ > Issue Type: Bug > Components: DOM >Affects Versions: 3.2.1, 3.2.2 > Environment: Oracle compiler version (supports c++11): > [hostname]/: /opt/developerstudio12.6/bin/CC -V > CC: Studio 12.6 Sun C++ 5.15 SunOS_i386 2017/05/30 > OS version: > [hostname]/: uname -a > SunOS hostname 5.10 Generic_150401-61 i86pc i386 i86pc >Reporter: Grzegorz Majka >Priority: Major > Attachments: xml_broken.xml, xml_ok.xml > > > Hi, > I have a problem running xerces on Solaris x86 platform compiled with > '-std=c++11' flag using Oracle developer studio 12.6. The compilation is fine > and the library works fine in all positive scenarios, but it fails with Abort > signal (core dumped) when an XML content to process is broken ending with the > error message: > "terminate called after throwing an instance of 'xercesc_3_2::XMLErrs::Codes'" > I was able to isolate the problem by using DOMPrint example run with a file > with an invalid xml content. > The positive scenario: > [hostname]/rome/homes/cit/gmajka/xerces_tests/solaris_322/xerces-c-3.2.2: > export > LD_LIBRARY_PATH=/rome/homes/cit/gmajka/xerces_tests/solaris_322/xerces-c-3.2.2/src/.libs:/opt/developerstudio12.6/lib/compilers/CC-gcc/lib > [hostname]/rome/homes/cit/gmajka/xerces_tests/solaris_322/xerces-c-3.2.2/samples: > ./.libs/DOMPrint xml_ok.xml > > > > > > > > The negative scenario: > [hostname]/rome/homes/cit/gmajka/xerces_tests/solaris_322/xerces-c-3.2.2/samples: > ./.libs/DOMPrint xml_broken.xml > Fatal Error at file > "/rome/homes/cit/gmajka/xerces_tests/solaris_322/xerces-c-3.2.2/samples/xml_broken.xml", > line 5, column 1 > Message: input ended before all started tags were ended; last tag started > is 'Hardware' > terminate called after throwing an instance of 'xercesc_3_2::XMLErrs::Codes' > Abort (core dumped) > I attach both xml_ok.xml and xml_broken.xml files for your reference. > Details: > 1) > Xerces version 3.2.1 (I also tried with 3.2.2 with the same behavior) > 2) > Oracle compiler version (supports c++11): > [hostname]/rome/homes/cit/gmajka/xerces_tests/solaris_322/xerces-c-3.2.2: > /opt/developerstudio12.6/bin/CC -V > CC: Studio 12.6 Sun C++ 5.15 SunOS_i386 2017/05/30 > OS version: > [hostname]/rome/homes/cit/gmajka/xerces_tests/solaris_322/xerces-c-3.2.2: > uname -a > SunOS hostname 5.10 Generic_150401-61 i86pc i386 i86pc > 3) > Configure options: > [hostname]/rome/homes/cit/gmajka/xerces_tests/solaris_322/xerces-c-3.2.2: > chmod +x ./configure.solaris; chmod +x config/install-sh; ./configure.solaris > CXX="/opt/developerstudio12.6/bin/CC" CC="/opt/developerstudio12.6/bin/cc" > LD="/opt/developerstudio12.6/bin/CC" LDFLAGS="-std=c++11 > -L/opt/developerstudio12.6/lib/compilers/CC-gcc/lib -lstdc++ -lgcc_s -lCrunG3 > -s" CFLAGS="-xO2 -D_XOPEN_SOURCE_EXTENDED=1 -D__EXTENSIONS__ -Kpic -mt" > CXXFLAGS="-xO2 -D_XOPEN_SOURCE_EXTENDED=1 -D__EXTENSIONS__ -Kpic -mt > -std=c++11" --disable-static --enable-xmlch-uint16_t > AR="/opt/developerstudio12.6/bin/CC -xar" ARFLAGS=-o --enable-transcoder-iconv > ... > ... > configure.solaris: Report: > configure.solaris: File Manager: POSIX > configure.solaris: Mutex Manager: standard > configure.solaris: Transcoder: iconv > configure.solaris: NetAccessor: socket > configure.solaris: Message Loader: inmemory > configure.solaris: XMLCh Type: uint16_t > 4) > "ldd" outputs: > Initially I had issues with "terminate called after throwing
[jira] [Commented] (XERCESC-2154) "terminate called after throwing an instance of 'xercesc_3_2::XMLErrs::Codes'" crash on Solaris x86 with invalid xml input (c++11)
[ https://issues.apache.org/jira/browse/XERCESC-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16637052#comment-16637052 ] Roger Leigh commented on XERCESC-2154: -- How exactly did you build Xerces-C++? Did you use the Autotools configure script, or the CMake build? Would it be possible to test with the other to see if this makes any difference? With the change to the standard libraries, is there any possibility that the exception isn't being caught due to some problem with typeinfo or exception handling? (I've seen this with GCC on FreeBSD with different libgcc versions in base and ports.) Is this a possibility on Solaris? By setting the error codes to different values, your _xml_broken.xml_ example sets the _retval_ to 4 on line 602 of _samples/src/DOMPrint/DOMPrint.cpp_. For this codepath to run, _errorsOccured_ must be set to true in one of the catch blocks above. On Linux, this works correctly testing locally. On your system, this uncaught exception can only occur if a thrown exception was not handled by _any_ of the catch blocks, including *catch(...)*. This indicates something is very wrong with the exception handling on your system with this build of Xerces-C++. Regards, Roger > "terminate called after throwing an instance of > 'xercesc_3_2::XMLErrs::Codes'" crash on Solaris x86 with invalid xml input > (c++11) > -- > > Key: XERCESC-2154 > URL: https://issues.apache.org/jira/browse/XERCESC-2154 > Project: Xerces-C++ > Issue Type: Bug > Components: DOM >Affects Versions: 3.2.1, 3.2.2 > Environment: Oracle compiler version (supports c++11): > [hostname]/: /opt/developerstudio12.6/bin/CC -V > CC: Studio 12.6 Sun C++ 5.15 SunOS_i386 2017/05/30 > OS version: > [hostname]/: uname -a > SunOS hostname 5.10 Generic_150401-61 i86pc i386 i86pc >Reporter: Grzegorz Majka >Priority: Major > Attachments: xml_broken.xml, xml_ok.xml > > > Hi, > I have a problem running xerces on Solaris x86 platform compiled with > '-std=c++11' flag using Oracle developer studio 12.6. The compilation is fine > and the library works fine in all positive scenarios, but it fails with Abort > signal (core dumped) when an XML content to process is broken ending with the > error message: > "terminate called after throwing an instance of 'xercesc_3_2::XMLErrs::Codes'" > I was able to isolate the problem by using DOMPrint example run with a file > with an invalid xml content. > The positive scenario: > [hostname]/rome/homes/cit/gmajka/xerces_tests/solaris_322/xerces-c-3.2.2: > export > LD_LIBRARY_PATH=/rome/homes/cit/gmajka/xerces_tests/solaris_322/xerces-c-3.2.2/src/.libs:/opt/developerstudio12.6/lib/compilers/CC-gcc/lib > [hostname]/rome/homes/cit/gmajka/xerces_tests/solaris_322/xerces-c-3.2.2/samples: > ./.libs/DOMPrint xml_ok.xml > > > > > > > > The negative scenario: > [hostname]/rome/homes/cit/gmajka/xerces_tests/solaris_322/xerces-c-3.2.2/samples: > ./.libs/DOMPrint xml_broken.xml > Fatal Error at file > "/rome/homes/cit/gmajka/xerces_tests/solaris_322/xerces-c-3.2.2/samples/xml_broken.xml", > line 5, column 1 > Message: input ended before all started tags were ended; last tag started > is 'Hardware' > terminate called after throwing an instance of 'xercesc_3_2::XMLErrs::Codes' > Abort (core dumped) > I attach both xml_ok.xml and xml_broken.xml files for your reference. > Details: > 1) > Xerces version 3.2.1 (I also tried with 3.2.2 with the same behavior) > 2) > Oracle compiler version (supports c++11): > [hostname]/rome/homes/cit/gmajka/xerces_tests/solaris_322/xerces-c-3.2.2: > /opt/developerstudio12.6/bin/CC -V > CC: Studio 12.6 Sun C++ 5.15 SunOS_i386 2017/05/30 > OS version: > [hostname]/rome/homes/cit/gmajka/xerces_tests/solaris_322/xerces-c-3.2.2: > uname -a > SunOS hostname 5.10 Generic_150401-61 i86pc i386 i86pc > 3) > Configure options: > [hostname]/rome/homes/cit/gmajka/xerces_tests/solaris_322/xerces-c-3.2.2: > chmod +x ./configure.solaris; chmod +x config/install-sh; ./configure.solaris > CXX="/opt/developerstudio12.6/bin/CC" CC="/opt/developerstudio12.6/bin/cc" > LD="/opt/developerstudio12.6/bin/CC" LDFLAGS="-std=c++11 > -L/opt/developerstudio12.6/lib/compilers/CC-gcc/lib -lstdc++ -lgcc_s -lCrunG3 > -s" CFLAGS="-xO2 -D_XOPEN_SOURCE_EXTENDED=1 -D__EXTENSIONS__ -Kpic -mt" > CXXFLAGS="-xO2 -D_XOPEN_SOURCE_EXTENDED=1 -D__EXTENSIONS__ -Kpic -mt > -std=c++11" --disable-static --enable-xmlch-uint16_t > AR="/opt/developerstudio12.6/bin/CC -xar" ARFLAGS=-o --enable-transcoder-iconv > ... > ... > configure.solaris: Report: > configure.solaris: File Manager: POSIX > configure.solaris:
[jira] [Closed] (XERCESC-2153) Tests can fail on Windows when run in parallel
[
https://issues.apache.org/jira/browse/XERCESC-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roger Leigh closed XERCESC-2153.
Resolution: Fixed
Fix Version/s: 3.2.2
Fixed in SVN r1840586. Running StdIn tests serially avoids contention with
other tests sharing the same input files. All the other tests can be run in
parallel.
> Tests can fail on Windows when run in parallel
> --
>
> Key: XERCESC-2153
> URL: https://issues.apache.org/jira/browse/XERCESC-2153
> Project: Xerces-C++
> Issue Type: Wish
> Components: Samples/Tests
>Affects Versions: 3.2.1
> Environment: Windows 10 x64 with VS2017 x64 build of Xerces-C++ 3.2.2
> prerelease.
>Reporter: Roger Leigh
>Assignee: Roger Leigh
>Priority: Minor
> Labels: test-fail, windows
> Fix For: 3.2.2
>
>
> Tests always pass when run serially, so I don't see this as a blocker for
> 3.2.2 unless it's indicative of a very long-standing problem internally in
> Xerces rather than that the tests were not originally written with parallel
> execution in mind.
> When running "ctest -jn" to run tests in parallel, tests can randomly fail.
> Looks like an interaction between tests when run at the same time. Some
> resource contention?
> The following is a reduced testcase, where I've found two tests which
> interact badly (there may be others). Both are using personal.xml as input.
> {{D:\xerces-c-3.2.2\b>ctest -C Release -j 4 -R "DOMPrint3|StdInParse2"}}
> {{Test project D:/xerces-c-3.2.2/b}}
> {{ Start 66: DOMPrint3}}
> {{ Start 70: StdInParse2}}
> {{1/2 Test #66: DOMPrint3 ***Failed 0.07 sec}}
> {{2/2 Test #70: StdInParse2 .. Passed 0.08 sec}}{{50%
> tests passed, 1 tests failed out of 2}}{{Total Test time (real) = 0.11
> sec}}{{The following tests FAILED:}}
> {{ 66 - DOMPrint3 (Failed)}}
> {{Errors while running CTest}}
> I can't reproduce on Linux, so it may well be Windows-specific due to file
> locking preventing multiple readers of a file? Is it due to one process
> having it held open on stdin while the other tries to open it. Running
> multiple StdInParse[123] tests or multiple DOMPrint[123] tests does not
> result in failure. But when the two are combined, it's always DOMPrint that
> fails; is it the open mode being used?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2153) Tests can fail on Windows when run in parallel
[
https://issues.apache.org/jira/browse/XERCESC-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roger Leigh updated XERCESC-2153:
-
Issue Type: Wish (was: Improvement)
> Tests can fail on Windows when run in parallel
> --
>
> Key: XERCESC-2153
> URL: https://issues.apache.org/jira/browse/XERCESC-2153
> Project: Xerces-C++
> Issue Type: Wish
> Components: Samples/Tests
>Affects Versions: 3.2.1
> Environment: Windows 10 x64 with VS2017 x64 build of Xerces-C++ 3.2.2
> prerelease.
>Reporter: Roger Leigh
>Assignee: Roger Leigh
>Priority: Minor
> Labels: test-fail, windows
>
> Tests always pass when run serially, so I don't see this as a blocker for
> 3.2.2 unless it's indicative of a very long-standing problem internally in
> Xerces rather than that the tests were not originally written with parallel
> execution in mind.
> When running "ctest -jn" to run tests in parallel, tests can randomly fail.
> Looks like an interaction between tests when run at the same time. Some
> resource contention?
> The following is a reduced testcase, where I've found two tests which
> interact badly (there may be others). Both are using personal.xml as input.
> {{D:\xerces-c-3.2.2\b>ctest -C Release -j 4 -R "DOMPrint3|StdInParse2"}}
> {{Test project D:/xerces-c-3.2.2/b}}
> {{ Start 66: DOMPrint3}}
> {{ Start 70: StdInParse2}}
> {{1/2 Test #66: DOMPrint3 ***Failed 0.07 sec}}
> {{2/2 Test #70: StdInParse2 .. Passed 0.08 sec}}{{50%
> tests passed, 1 tests failed out of 2}}{{Total Test time (real) = 0.11
> sec}}{{The following tests FAILED:}}
> {{ 66 - DOMPrint3 (Failed)}}
> {{Errors while running CTest}}
> I can't reproduce on Linux, so it may well be Windows-specific due to file
> locking preventing multiple readers of a file? Is it due to one process
> having it held open on stdin while the other tries to open it. Running
> multiple StdInParse[123] tests or multiple DOMPrint[123] tests does not
> result in failure. But when the two are combined, it's always DOMPrint that
> fails; is it the open mode being used?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2153) Tests can fail on Windows when run in parallel
[
https://issues.apache.org/jira/browse/XERCESC-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16610530#comment-16610530
]
Roger Leigh commented on XERCESC-2153:
--
Putting some debug messages in WindowsFileMgr::fileOpen (called from
BinFileInputStream from LocalFileInputSource), shows that the HRESULT is
0x80070020 (sharing violation) which meets the hypothesis above. The input
file on stdin must be opened without FILE_SHARE_WRITE. This isn't a bug in
Xerces-C++, it's due to the way the CMake execute_process function sets up
pipes for STDIN with read and write access. I have created a ticket for that
here which contains more details:
https://gitlab.kitware.com/cmake/cmake/issues/18359
> Tests can fail on Windows when run in parallel
> --
>
> Key: XERCESC-2153
> URL: https://issues.apache.org/jira/browse/XERCESC-2153
> Project: Xerces-C++
> Issue Type: Improvement
> Components: Samples/Tests
>Affects Versions: 3.2.1
> Environment: Windows 10 x64 with VS2017 x64 build of Xerces-C++ 3.2.2
> prerelease.
>Reporter: Roger Leigh
>Assignee: Roger Leigh
>Priority: Minor
> Labels: test-fail, windows
>
> Tests always pass when run serially, so I don't see this as a blocker for
> 3.2.2 unless it's indicative of a very long-standing problem internally in
> Xerces rather than that the tests were not originally written with parallel
> execution in mind.
> When running "ctest -jn" to run tests in parallel, tests can randomly fail.
> Looks like an interaction between tests when run at the same time. Some
> resource contention?
> The following is a reduced testcase, where I've found two tests which
> interact badly (there may be others). Both are using personal.xml as input.
> {{D:\xerces-c-3.2.2\b>ctest -C Release -j 4 -R "DOMPrint3|StdInParse2"}}
> {{Test project D:/xerces-c-3.2.2/b}}
> {{ Start 66: DOMPrint3}}
> {{ Start 70: StdInParse2}}
> {{1/2 Test #66: DOMPrint3 ***Failed 0.07 sec}}
> {{2/2 Test #70: StdInParse2 .. Passed 0.08 sec}}{{50%
> tests passed, 1 tests failed out of 2}}{{Total Test time (real) = 0.11
> sec}}{{The following tests FAILED:}}
> {{ 66 - DOMPrint3 (Failed)}}
> {{Errors while running CTest}}
> I can't reproduce on Linux, so it may well be Windows-specific due to file
> locking preventing multiple readers of a file? Is it due to one process
> having it held open on stdin while the other tries to open it. Running
> multiple StdInParse[123] tests or multiple DOMPrint[123] tests does not
> result in failure. But when the two are combined, it's always DOMPrint that
> fails; is it the open mode being used?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2153) Tests can fail on Windows when run in parallel
Roger Leigh created XERCESC-2153:
Summary: Tests can fail on Windows when run in parallel
Key: XERCESC-2153
URL: https://issues.apache.org/jira/browse/XERCESC-2153
Project: Xerces-C++
Issue Type: Improvement
Components: Samples/Tests
Affects Versions: 3.2.1
Environment: Windows 10 x64 with VS2017 x64 build of Xerces-C++ 3.2.2
prerelease.
Reporter: Roger Leigh
Assignee: Roger Leigh
Tests always pass when run serially, so I don't see this as a blocker for 3.2.2
unless it's indicative of a very long-standing problem internally in Xerces
rather than that the tests were not originally written with parallel execution
in mind.
When running "ctest -jn" to run tests in parallel, tests can randomly fail.
Looks like an interaction between tests when run at the same time. Some
resource contention?
The following is a reduced testcase, where I've found two tests which interact
badly (there may be others). Both are using personal.xml as input.
{{D:\xerces-c-3.2.2\b>ctest -C Release -j 4 -R "DOMPrint3|StdInParse2"}}
{{Test project D:/xerces-c-3.2.2/b}}
{{ Start 66: DOMPrint3}}
{{ Start 70: StdInParse2}}
{{1/2 Test #66: DOMPrint3 ***Failed 0.07 sec}}
{{2/2 Test #70: StdInParse2 .. Passed 0.08 sec}}{{50% tests
passed, 1 tests failed out of 2}}{{Total Test time (real) = 0.11 sec}}{{The
following tests FAILED:}}
{{ 66 - DOMPrint3 (Failed)}}
{{Errors while running CTest}}
I can't reproduce on Linux, so it may well be Windows-specific due to file
locking preventing multiple readers of a file? Is it due to one process having
it held open on stdin while the other tries to open it. Running multiple
StdInParse[123] tests or multiple DOMPrint[123] tests does not result in
failure. But when the two are combined, it's always DOMPrint that fails; is it
the open mode being used?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
