from:"Roger Leigh"



 [ 
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

Removal from project

2023-04-26 Thread Roger Leigh

Hi,

I'm afraid that I no longer use actively use Xerces-C++ for any of my current 
projects and I have been far too time constrained to participate in any way for 
some time.  Please could I be removed from the project?

Thanks all for allowing me to contribute to the project over the last few 
years, it was invaluable for complex XML processing and validation in my 
previous job, and without it we would not have been able to do the XML 
processing in C++ at all.  Xerces-C++ is, unfortunately, quite outdated and 
like for Xalan-C++ it might be worth considering moving to the attic at the 
point where it is no longer really a viable project (I think it's been at this 
point for some years, myself).

Kind regards,
Roger

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

RE: Prepping a 3.2.4 release

2022-10-22 Thread Roger Leigh

Hi Scott,


With regard to the retirement discussion, I just wanted to forward this message 
on from Even Rouault who was having trouble subscribing and posting to the list:


Hi,

I have given a try to 3.2.4rc1 against the GDAL (https://gdal.org / 
https://github.com/OSGeo/gdal) regression test suite, and everything works like 
a charm.

Regarding the discussion about the possibility of retirement of Xerces-C++, I 
just want to say that Xerces-C++ has unique features that I'm not aware of in 
other C/C++ open-source libraries and that we strongly leverage in the above 
mentioned open-source GDAL project. In one of the drivers of GDAL, the GMLAS 
one (Geographic Markup Language application Schema - 
https://gdal.org/drivers/vector/gmlas.html), we use not only Xerces-C++ XML 
parsing capabilities and XML Schema validation ones, but the driver depends on 
using XML Schema grammar classes of Xerces-C++ to fully understand the XML 
schema constructs and derive a whole relational database table structure. In 
particular we use a lot of the classes at xercesc/framework/psvi/XS*.hpp. This 
driver is at the core of the 
https://github.com/BRGM/gml_application_schema_toolbox plugin for the QGIS open 
source project.

Even if the XML tech is less trendy those years, it is still used in a number 
of contexts of sharing of information with geographic content in various 
application fields: EU Inspire GML 
(https://inspire.ec.europa.eu/document-tags/data-specifications), geological 
data (http://geosciml.org/), etc. So we'd for sure like seeing Xerces-C++ 
existence to go on, even in a minimal maintenance mode.

Best regards,

Even



And one bit extra from myself.  For anyone who isn't following the Xalan-C 
mailing list, the outcome from the vote on the lists was to retire Xalan-C and 
move it to the Attic.  
https://lists.apache.org/thread/oj90kfd9ckt57yw1tthxlryylhjgrwsj is the 
relevant thread.


Regards,
Roger


> -Original Message-
> From: Cantor, Scott 
> Sent: 05 October 2022 21:56
> To: c-dev@xerces.apache.org
> Subject: Re: Prepping a 3.2.4 release
> 
> >I'm afraid that due to other commitments, I've been unable to do
> > any further work on the master branch for 4.0.0, and it's unlikely
> > that this will change in the near future.  If anything, I'm unlikely
> > to be able to spend much more time on the project at all, and I might
> > have to end my involvement entirely.
> 
> That isn't surprising, but I appreciate the forewarning. That's why I didn't
> really favor trying to do a 4.0.0 originally, I just don't think there's 
> enough
> long term resource commitment for that to be a wise choice.
> 
> Were it my decision, I would post a warning that the code is being sunsetted
> and anybody on it should be getting off it. Which I think is pretty clear as 
> it is,
> but it's the responsible and proper thing to just say so.
> 
> > We do have a large accumulation of patches which would certainly be
> > worth carrying over to the 3.2 branch where applicable,
> 
> Yes, that's my goal right now, within reason. I simply can't "fix" most things
> unfortunately because I don't know the code and the risk of breaking things
> is much higher than the payoff in most cases.
> 
> > When it comes to ABI compatibility checking, I'll be happy to do runs
> > of some of the ABI checking tools to look for any compatibility issues
> > with the ABI or API, if you haven't already done this.
> 
> My approach, as we've been debating, is just to avoid the possibility
> whereever I can by not touching headers, but I am willing to accept that I'm
> much more conservative about this than I should be and things may not
> work quite the way I've always thought they did.
> 
> >It would be nice to get the CI fixed up again before making a
> > release.  It's probably not too difficult to get working again; the CI
> > image and the build logic probably need updating to cope with external
> > changes which broke it in the interim.  I can try to find a bit of
> > time to inspect this--it's not too difficult, just takes time to wait for 
> > builds
> for each change to test it.
> 
> I definitely can't spend time there, so if you can, that's great. If not, 
> it's best
> to wind down anything I can't support unless somebody else steps up to take
> it over.
> 
> Thanks for checking in.
> 
> -- Scott
> 
> 
> B
> 
> CB  [  X  ܚX KK[XZ[
> 
>   Y] ][  X  ܚX P\  \˘\X K ܙ B  ܈Y][ۘ[  [X[  K[XZ[
> 
>   Y] Z[\  \˘\X K ܙ B

RE: Probably a 3.2.5 fix coming

2022-10-19 Thread Roger Leigh

FYI:

bullseye/stable:  GCC 10.2
buster/oldstable: GCC 8.3
stretch:  GCC 6.3

So C++11 should have been the default in the last three Debian major releases.

I agree that backing out the nullptr use is the best course of action 
irrespective of any other considerations.

Kind regards,
Roger

> -Original Message-
> From: Cantor, Scott 
> Sent: 19 October 2022 14:33
> To: c-dev@xerces.apache.org
> Subject: Re: Probably a 3.2.5 fix coming
> 
> On 10/19/22, 9:29 AM, "Robert Hairgrove"
>  wrote:
> 
> >However, it is not the default compile mode until GCC 6.1, so it would
> >have to be enabled with the `-std=c++11` command-line option.
> 
> That is not what is observed. I built it clean on Debian, without any override
> of that flag. So there's something else going on for a particular build, and 
> g++
> claims it uses a baseline that's past 2011. It may not be 100% standard, but
> it's enough to get nullptr to work.
> 
> >Many projects, Qt for example, replaced all pointer 0's with `nullptr`
> >sometime between 5.12 and 5.15, so perhaps it wouldn't be such a
> > bad  thing just to leave `nullptr` in there?
> 
> There are insufficient resources to do things like that and risk breakage. It
> needs to build regardless so canaries are not something this project can
> afford. If it was a live code base, I probably would agree.
> 
> > If there ever is another major
> > release, I think this should be used instead of `0` (or `NULL`??
> 
> There will never be another major release unless something substantially
> changes.  Or a minor.
> 
> -- Scott
> 
> 
> 
> -
> To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
> For additional commands, e-mail: c-dev-h...@xerces.apache.org


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

RE: Probably a 3.2.5 fix coming

2022-10-18 Thread Roger Leigh

Hi Scott,

All of our PRs are testing on Travis-CI using Ubuntu 18.04 with GCC 7.5 (e.g. 
https://app.travis-ci.com/github/apache/xerces-c/jobs/552979282).
So that should be near enough to Debian, and it's not so cutting edge that the 
compiler capabilities we are testing against aren't present on all semi-recent 
Linux distributions.

nullptr is a language keyword, so that should just have worked.  Unless an 
older language standard was being explicitly forced, the use of nullptr should 
be benign.

I would be interested to see the details of the failure.

Thanks,
Roger

> -Original Message-
> From: Cantor, Scott 
> Sent: 19 October 2022 03:26
> To: c-dev@xerces.apache.org
> Subject: Probably a 3.2.5 fix coming
> 
> Build on Debian's breaking, apparently some of those "safe" patches are
> probably missing header includes on certain strict compilers, so I'll likely 
> have
> to patch and do another release once I bottom that out.
> 
> I assume Debian wasn't on anybody's check list of tested builds.
> 
> -- Scott
> 
> 
> B�
> CB��[��X��ܚX�KK[XZ[
> 
> ��Y]�][��X��ܚX�P\��\˘\X�K�ܙ�B��܈Y][ۘ[��[X[
> ��K[XZ[
> 
> ��Y]�Z[\��\˘\X�K�ܙ�B�

RE: 3.2.4 release candidate

2022-10-15 Thread Roger Leigh

Hi Scott,

+1 from me.

I've tested on FreeBSD/amd64.  All the tests pass, plus an extended set of 
tests used by my own application and its unit and integration tests.

Kind regards,
Roger

> -Original Message-
> From: Cantor, Scott 
> Sent: 14 October 2022 17:34
> To: c-dev@xerces.apache.org
> Subject: Re: 3.2.4 release candidate
> 
> FWIW we still need one more +1 vote I believe.
> 
> -- Scott
>

RE: 3.2.4 release candidate

2022-10-14 Thread Roger Leigh

> -Original Message-
> From: Cantor, Scott 
> Sent: 14 October 2022 17:34
> To: c-dev@xerces.apache.org
> Subject: Re: 3.2.4 release candidate
> 
> FWIW we still need one more +1 vote I believe.

I will try to find time to do some testing this weekend.

Regards,
Roger

Re: Discussion of Xerces-C++ project health and possibility of retirement

2022-10-10 Thread Roger Leigh

> -Original Message-
> From: Boris Kolpackov 
> Sent: 10 October 2022 17:17
> To: c-dev@xerces.apache.org
> Subject: Re: Prepping a 3.2.4 release
> 
> Cantor, Scott  writes:
> 
> > On 10/10/22, 10:14 AM, "Boris Kolpackov" 
> wrote:
> >
> > > What would be the other options for XML Schema validation usable
> > > from C++?
> >
> > Libxml2?
> >
> > Says it supports XML Schema 1.0 (which is all Xerces ever did AFAIK).
> 
> Last time I checked (which was admittedly a few years ago), while they listed
> XML Schema support on their front page, if you dug deeper, it quickly
> became apparent that support was WIP/incomplete.

It might not support every feature, but is the current implementation "good 
enough" for its userbase?  It's worked with the schemas I've validated with it 
in the past.  If there are unimplemented bits [the docs could simply be 
incorrect here], and those are restricted to obscure features which aren't in 
common use, then the lack of these bits has no practical effect upon using the 
library.

Another option is QtXML which also offers schema validation, and which also has 
worked well for me in the past.

Also Microsoft MSXML.  I've not used it myself, but if you're using this 
platform it's an obvious option.

> > >And, no, rewriting everything in a different language just because
> > >Xerces-C++ has some bugs is not a sensible step.
> >
> > That is a matter of opinion, because if a security bug pops up (*)
> > that nobody can fix, you (and I) are going to be in a very, very bad 
> > position.
> > Moving to a different language is the only sensible option if in fact
> > there is nothing else to use, and I am doing exactly that, despite the
> > many hours it will take.
> 
> Not every application that uses Xerces-C++ is security sensitive. In fact, 
> IMO,
> it's insane to parse untrusted XML regardless of the
> implementation/language used -- the format is just too complex to have any
> trust in the implementation. Also note that if you think
> Xerces-C++ is somehow exceptionally bad, you are mistaken.

I don't think it's especially relevant to compare Xerces-C++ against other 
libraries in this manner.  Whether other libraries are better or worse than 
Xerces-C++ is a distraction from the question being addressed: is Xerces-C++ as 
an Apache project a viable ongoing concern with a community which are willing 
and able to support it for the future?

>From the discussion so far, it's clear that there are strong differences of 
>opinion on the list regarding whether or not it is time to retire Xerces-C++.  
>We will need to call for a vote on this after this discussion is completed, 
>but before we do that it would be useful to look at this a bit more 
>objectively and assess the criteria by which we might judge the activity and 
>health of the project.  By what criteria would we judge the project to be in a 
>healthy state?  Or an unhealthy state?

As an example of one way to summarise the data, this is a summary of committers 
as of today: 
https://codelibreconsulting.sharepoint.com/:x:/s/Opensourcesoftware/EYoNqCnjG-JBnHq-yZqhhDkBxYx2CDbWNT4j7QAWqL_maA?e=iBwfSf
 and it includes each unique committer, the number of commits they made and the 
last date they made a commit.  However, note that "most recent" is quite a 
crude view of a person's contribution history.  I've just repointed the repo 
location from SVN to Git at https://openhub.net/p/xerces-c and this will 
generate some reasonably detailed contribution graphs and other repository 
metrics once it fetches and processes the current xerces-3.2 branch.

One simple question to ask would be: how many active contributors does the 
project have today?

I would think the answer to this would be: effectively zero.  Neither myself 
nor Scott are actively contributing to the project, and we are the two most 
recent contributors of anything more than trivial one-off fixes.  Next after 
that is Even who has done some static analysis work--all bugfixing of resource 
leaks etc.  After that there is Alberto who has made infrequent and irregular 
commits.  Then there is yourself, with an 8 year gap in between.  Looking at 
the contributors, there has been a gap of over a decade during which time there 
was really only one person who made any changes at all (Alberto), and his 
activity tailed off significantly after ~2014.  Scott (starting 2015) and 
myself (starting 2017) did some maintenance releases and did some bugfixing, 
but that's basically it.  I'm leaving; I no longer use Xerces or even much XML 
at all.  Scott said he was migrating away gradually.  Where does that leave the 
project?  Who is actually going to be maintaining it, doing all of the security 
work, user support, maintenance releases, testing, CI upkeep, PR review and 
testing of contributed fixes, etc.  Both Scott and myself have put in a *lot* 
of work behind the scenes to keep this project going for the last 8 years.  
Without anyone picking up these ongoing

RE: Prepping a 3.2.4 release

2022-10-07 Thread Roger Leigh

Dear all,

We had a similar conversation to this on the Xalan mailing list a few months
back:

https://lists.apache.org/list?d...@xalan.apache.org:2022-6 (Future of Xalan-C)
https://lists.apache.org/list?d...@xalan.apache.org:2022-7 (Retire Xalan to the
Attic) [Xalan-J]

In both cases there was no definitive decision, but if you take the time to
read through the first thread it provides some overview of the historical
contributions to the project and the past and current maintainers. The bottom
line is this: there are no maintainers, haven't been for over a decade.. I'm
stopping the small effort I made, and the previous people involved have moved
onto Saxon, and no longer use it. The project, while notionally functional, is
not maintained, and it has no future unless people step up with real commitment
to do the necessary work. No real work has been done on the project since 2005
other than two point releases incorporating small bugfixes. It's dead, and
it's been dead for a long time now. I will revisit this and try to get a
conclusion, and while any decision made for Xerces-C++ will also affect Xalan
immediately, it should retired in any case.

For Xalan-J, this actually spurred someone into action, and some work is
currently being done. However, it remains to be seen if this is sufficient to
revive the project--a short term burst of activity does not mean the project is
healthy for the longer term.

For Xerces-C++, I think we're in a very similar situation to Xalan-C. We have
sporadic maintenance work by Scott and myself, and recently we've had Even
Rouault provide fixes based upon static analysis to fix some longstanding
issues. But other than that, we don't have much activity. I do think we need
to be honest with our users about the true status of this project. If it's not
maintained, we should consider moving it to the Attic. I personally think that
would be the correct course of action. I don't think we should be encouraging
new use of Xerces-C++ if it's an unmaintained project with a legacy codebase,
it's doing them a disservice to pretend that it's viable and well supported,
which it is not.

I originally used Xerces+Xalan for XML and XSLT processing in C++. As Boris
said, they are the only game in town. But that doesn't necessarily mean they
are a sensible choice or the right choice. I only joined the project because I
was struggling so much to incorporate them into a modern C++11 (now C++14)
codebase. It's really painful:

* It predates adoption of Standard C++ (98)
* It doesn't use standard exception types
* It doesn't use conventional memory allocation strategies
* It doesn't use conventional character types
* Memory management is a pain, which is exacerbated by the need to do so much
manual string conversions (e.g. UTF-8 to UTF-16 and vice versa).
* The build system was problematic on modern platforms

A lot of the work I've done is to gradually address some of these. Like
allowing char16_t as XMLCh. And adding CMake support. Clang support and fixes
to work with modern compilers. And adding support for other standard library
features. But while all of these things are small improvements which have kept
Xerces-C++ usable on modern platforms and improved its interoperability with
other libraries, they don't even start to tackle some of the bigger problems.
It's still an archaic codebase from the '90s, with all of the design problems
implicit in that. It's not a library anyone is going to use out of choice, but
out of necessity in the absence of any other options. If Xerces-C++ was to be
retired, projects will need to consider other options, be that other libraries,
or other languages.

I did want to rectify some of these, which is why I started some clean-ups on
the 4.0.0 branch. But we have to be realistic: there is not the will or the
manpower to do this, and I suspect there isn't much user demand for this
either--this is a legacy project with legacy users.

I've updated the git statistics I did earlier in the year, which can be viewed
or downloaded here:
https://codelibreconsulting.sharepoint.com/:x:/s/Opensourcesoftware/EabAzxgzU3pCjUSKSVvWjZgBlUGZUb91q2PVMkGk1oaIHw?e=MVBvPA.
This includes Scott's recent changes for this month to date. Overall, you
can see that the major development happened early on, that it reached maturity
in the late 2000s, and it has been moribund for the last decade. This is the
contributor summary since 01 Oct 2022:

$ git shortlog -s --oneline --all --since "01 OCT 2012"
35 Alberto Massari
1 Chris Mc
26 Even Rouault
1 Fred Hornsey
183 Roger Leigh
171 Scott Cantor

I only joined out of necessity to keep it going for use by my work projects,
continued to do some work afterward, and I'm going to cease that entirely.
Even is in a similar situation. I get the impression Scott might be in a
similar situation as well. I don't think any of us h

RE: Prepping a 3.2.4 release

2022-10-05 Thread Roger Leigh

Hi Scott,

I'm afraid that due to other commitments, I've been unable to do any further 
work on the master branch for 4.0.0, and it's unlikely that this will change in 
the near future.  If anything, I'm unlikely to be able to spend much more time 
on the project at all, and I might have to end my involvement entirely.  I'm no 
longer actively using Xerces-C++, since the projects I used it for have wound 
down.  I don't think there are any particularly compelling features on the 
master branch which anyone would miss.  It was primarily some cleanup to remove 
obsolete stuff and bring it up to date with modern C++ standards in a very 
limited way.  While it would have been nice to continue this and make a 4.0.0 
release, I'm afraid I will have to leave this to someone else.

We do have a large accumulation of patches which would certainly be worth 
carrying over to the 3.2 branch where applicable, so I'm sure a point release 
with these fixes would be much appreciated by the wider community.  When it 
comes to ABI compatibility checking, I'll be happy to do runs of some of the 
ABI checking tools to look for any compatibility issues with the ABI or API, if 
you haven't already done this.

It would be nice to get the CI fixed up again before making a release.  It's 
probably not too difficult to get working again; the CI image and the build 
logic probably need updating to cope with external changes which broke it in 
the interim.  I can try to find a bit of time to inspect this--it's not too 
difficult, just takes time to wait for builds for each change to test it.

Kind regards,
Roger

> -Original Message-
> From: Cantor, Scott 
> Sent: 05 October 2022 14:57
> To: c-dev@xerces.apache.org
> Subject: Prepping a 3.2.4 release
> 
> Resending...
> 
> As the traffic indicates, I've got a rare window to actually do some work on a
> release, so I'm aiming to get a 3.2.4 patch done quickly.
> 
> I do not have the cycles or the will (or believe it's in the interest of the
> project) to get a 4.0 out so I'm not working on that.
> 
> I need to get my arms around what's actually committed on the branch and
> what might be left to commit that's safe to do, so I'm starting there.

[jira] [Commented] (XERCESC-2236) Dependencies aren't loaded when using provided CMake config package

2022-10-05 Thread Roger Leigh (Jira)



[ 
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

2022-10-05 Thread Roger Leigh (Jira)



[ 
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

2022-10-05 Thread Roger Leigh (Jira)



 [ 
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

RE: Xerces 4 and XML Schema 1.1 validation

2022-08-29 Thread Roger Leigh

Hi Robert,

I don't think you've overlooked anything here.

Kind regards,
Roger

> -Original Message-
> From: Robert Hairgrove 
> Sent: 29 August 2022 10:10
> To: c-dev@xerces.apache.org; c-us...@xerces.apache.org
> Subject: Re: Xerces 4 and XML Schema 1.1 validation
> 
> It looks like I was confused by the statements found here under "Features"
> (https://xerces.apache.org/xerces-c/):
> 
>   * Conforms to
>   o XML 1.0 (Third Edition)
> , W3C
> Recommendation
>   o XML 1.1 (First Edition)
> , W3C
> Recommendation (Note: section 2.13 Normalization Checking has
> not been implemented)
> 
> After doing some more research, I realize that I am looking for XSD 1.1
> support (which Xerces-J apparently has, but Xerces-C++ does not) and not
> XML 1.1 which has nothing to do with XSD.
> 
> Or did I overlook something else?

RE: Xerces 4 and XML Schema 1.1 validation

2022-08-28 Thread Roger Leigh

Hi Robert,

If you compiled without network access, then you'll need to be sure that all of 
the schema files are accessible, for example by implementing a custom 
EntityResolver.  At a minimum, you'll want to provide your own schemas, plus 
any schemas they depend upon, e.g. XMLSchema.

I would suggest testing with a working netaccessor before turning it off, to 
eliminate the possibility that it just can't fetch the schemas, before going 
further with the custom EntityResolver, in case there are other underlying 
issues which haven't been identified yet.

By the way, the master branch (4.0.0) is not released yet, and while no issues 
have been reported to date, you might possibly hit problems using it.  I would 
recommend the xerces-3.2 stable branch or the 3.2.3 stable release.

Kind regards,
Roger

> -Original Message-
> From: Robert Hairgrove 
> Sent: 28 August 2022 15:17
> To: c-dev@xerces.apache.org; c-us...@xerces.apache.org
> Subject: Re: Xerces 4 and XML Schema 1.1 validation
> 
> BTW, I compiled Xerces-C++ with network access disabled since my users will
> not necessarily be connected to the internet, or will be behind a firewall.
> 
> -
> 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

2021-11-23 Thread Roger Leigh (Jira)



[ 
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

2021-10-24 Thread Roger Leigh (Jira)



[ 
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

2021-09-20 Thread Roger Leigh (Jira)



[ 
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

2021-09-20 Thread Roger Leigh (Jira)

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

2021-09-20 Thread Roger Leigh (Jira)

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

Xerces-C++ 3.2.4

2021-08-23 Thread Roger Leigh

Hi folks,

 

Would it be possible to add 3.2.4 as a new unreleased version in Jira?  As you 
have probably seen, Even Rouault has made several changes to fix bugs on the 
3.2 branch, and it would be useful to release them.

 

Are there any other needed fixes to go into a new 3.2 point release?

 

Thanks all,

Roger

[jira] [Created] (XERCESC-2219) XMLReader constructor: memory leak when refreshRawBuffer() throws

2021-08-23 Thread Roger Leigh (Jira)

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

2021-08-23 Thread Roger Leigh (Jira)

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

2021-08-23 Thread Roger Leigh (Jira)

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

Re: German translation of loadable message list

2021-01-03 Thread Roger Leigh

Hi Robert,


Yes, sorry I couldn’t be more positive about it.  If it was as simple as making 
and submitting a translation file, I’d have been all for it.

Part of the complexity here is due to the age of the project and the lack of 
standard, portable, translation systems at the time it was originally written.  
I don’t think attempting to support several platform-specific (windows, 
catgets) and one portable (ICU) system was a good choice, particularly without 
any translations to actively test any of them!  The Qt system is very good, but 
would require taking on Qt dependencies.  If we had mandated ICU from the start 
so it could be relied upon to be present, then I think that would have been the 
way forward.

I think it could be made to work, but it will require significant effort, and 
all of the existing translation machinery is in a completely unknown state, 
since none of it has been exercised with anything but en_US.  I’m afraid that 
given the lack of maintenance for Xerces-C++, if I was to make a recommendation 
here, it would be to completely strip out all of the translation machinery, 
because right now it has zero value since it just adds complexity for no 
benefit.


Kind regards,
Roger


> On 3 Jan 2021, at 10:38, Robert Hairgrove  wrote:
> 
> Thanks, Roger -- it's really too bad, because I would have liked to 
> contribute this. But I suspected as much after browsing the source code a 
> little more.
> 
> The XMLErrorReporter interface receives the numeric code used to look up the 
> error string as the first argument to its virtual error() function which is 
> overloaded by SAX2XMLReaderImpl (et al.) along with the error text itself. 
> However, the error code is not used by the overload, only the already 
> formatted text itself is used.
> 
> If there were some way to pass this numeric code on to the client, it would 
> be trivial to set up a mapping object to return a localised version of the 
> error string. After all, only a few alternate locales would usually need to 
> be supported by any given application, and this is most easily managed by 
> some kind of plugin mechanism (for example, see how the Qt framework does it 
> -- IMHO, those people have it nailed down pretty well).
> 
> I agree that all translations should be managed by a single interface instead 
> of having all the different message loaders presently implemented.
> 
> Cheers,
> Robert
> 
> --
> 
> On 02.01.21 18:02, Roger Leigh wrote:
>> Hi Robert,
>> 
>> 
>> While the Xerces-C++ codebase notionally supports translation, I’m unaware 
>> of any translations ever having been publicly submitted or used in the 
>> lifetime of the project to date.  So for the conventions indicated in the 
>> XML file, which were likely written many years ago, I wouldn’t treat them as 
>> hard and fast rules for a translation—there simply hasn’t been the need to 
>> revisit it or any experience with translations which influenced it.
>> 
>> It’s not likely that the translation will work without some additional 
>> support work being done on the build system side, both for the CMake build 
>> and the Autoconf/Automake build.  It’s currently set up to build the en_US 
>> translation, and anything new will need adding in.  It might possibly need 
>> logic writing to support selection of the language; it’s quite likely 
>> untested and possibly incomplete.
>> 
>> To complicate matters we currently support several alternative translation 
>> systems.  I did suggest last year we should drop some of them to make this 
>> more maintainable.
>> 
>> 
>> Kind regards,
>> Roger
>> 
>>> On 2 Jan 2021, at 16:48, Robert Hairgrove  wrote:
>>> 
>>> I have built the latest version of Xerces-C++ 3.2.3 on Linux Ubuntu 18.04 
>>> LTS and would like to translate the loadable message file 
>>> "XMLErrList_EN_US.Xml" located under "src/xercesc/NLS/EN_US/" into German.
>>> 
>>> At the top of the XML file are some instructions which don't play well with 
>>> German:
>>> 
>>> "(...)  - All messages start with a lower-case letter (except where
>>>a name is used as the first word) and do not have a period
>>>at the end."
>>> 
>>> Leaving a period (AKA "full stop") off of the string's end is OK. But 
>>> German language uses upper-case initial letters for all nouns, not just 
>>> words at the beginning of a sentence. Also, since many of the terms should 
>>> be left in English which refer to XML names, these should be enclosed in 
>>> single or double quotes since they are not German.
>>> 
>>> Is th

Re: German translation of loadable message list

2021-01-02 Thread Roger Leigh

Hi Robert,

While the Xerces-C++ codebase notionally supports translation, I’m unaware of 
any translations ever having been publicly submitted or used in the lifetime of 
the project to date.  So for the conventions indicated in the XML file, which 
were likely written many years ago, I wouldn’t treat them as hard and fast 
rules for a translation—there simply hasn’t been the need to revisit it or any 
experience with translations which influenced it.

It’s not likely that the translation will work without some additional support 
work being done on the build system side, both for the CMake build and the 
Autoconf/Automake build.  It’s currently set up to build the en_US translation, 
and anything new will need adding in.  It might possibly need logic writing to 
support selection of the language; it’s quite likely untested and possibly 
incomplete.

To complicate matters we currently support several alternative translation 
systems.  I did suggest last year we should drop some of them to make this more 
maintainable.

Kind regards,
Roger

> On 2 Jan 2021, at 16:48, Robert Hairgrove  wrote:
> 
> I have built the latest version of Xerces-C++ 3.2.3 on Linux Ubuntu 18.04 LTS 
> and would like to translate the loadable message file "XMLErrList_EN_US.Xml" 
> located under "src/xercesc/NLS/EN_US/" into German.
> 
> At the top of the XML file are some instructions which don't play well with 
> German:
> 
> "(...)  - All messages start with a lower-case letter (except where
>a name is used as the first word) and do not have a period
>at the end."
> 
> Leaving a period (AKA "full stop") off of the string's end is OK. But German 
> language uses upper-case initial letters for all nouns, not just words at the 
> beginning of a sentence. Also, since many of the terms should be left in 
> English which refer to XML names, these should be enclosed in single or 
> double quotes since they are not German.
> 
> Is this a problem? I don't want to go to the trouble of creating translations 
> for hundreds of strings only to discover that they cannot be used due to the 
> way they are processed after being loaded.
> 
> (Or perhaps someone has already done this chore?)
> 
> 
> -
> To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
> For additional commands, e-mail: c-dev-h...@xerces.apache.org
> 

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

Re: https support

2020-08-17 Thread Roger Leigh


On 17/08/2020 10:22, Michael Behrisch wrote:


Hi,
we are currently using Xerces-C++ on Linux, Windows and MacOS for
parsing XML inputs and validating it against schemas. The schemas (like
https://sumo.dlr.de/xsd/routes_file.xsd) are on a public web server
which enforces https and I have some questions about Xerces-C++ here.

I understand that the https support depends on the net accessor used but
it is not clear to me which accessor really supports it.
Libcurl probably does (if built with ssl enabled), so we are fine under
Linux because it is generally available?

Winsock does not support https?

Can I find out at runtime whether I am using a Xerces-C++ with https
support (other than trial and error) to give at least a meaningful error
message?

I saw that there are libcurl implementations for Windows as well:
https://stackoverflow.com/questions/53861300/how-do-you-properly-install-libcurl-for-use-in-visual-studio-2017
but the docs say libcurl does not work with Windows. Did nobody try yet
or are there any major roadblocks?



Hi Michael,


I think that CURL should work just fine on Windows.  The socket/winsock 
options are plain sockets with no SSL support.



Looking at how the netaccessor selection is done, it's completely 
compile-time and the setting is in config.h which isn't installed, so 
it's not possible to determine the netaccessor in use at runtime or 
compile time as an end-user of Xerces-C++.  If the netaccessor symbols 
get exported you could possibly see if you can access the appropriate 
symbols, but it would be both hacky and fragile to do so.



I did suggest a couple of months back that in the current day and age of 
HTTPS everywhere, we might want to consider removing the built-in socket 
support and only provide netaccessors which support HTTPS.  This would 
guarantee working HTTPS support (the alternative being no network 
support at all).  See https://issues.apache.org/jira/browse/XERCESC-2207



Kind regards,

Roger


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

Re: New features for xerces-c 4.0.0?

2020-07-16 Thread Roger Leigh


Hi Francesco,


To clarify a few points in your message. Xerces-C++ has always been 
effectively UTF-16-only.  Previously the 16-bit type used to represent 
XMLCh was one of several possible types, including char16_t, wchar_t, 
uint16_t, unsigned short or unsigned int or possibly others, depending 
upon your platform.  The change I proposed for the 4.0.0 was to switch 
to C++11/14 and use char16_t.  I.e. standardising upon the standard type 
for a UTF-16 codepoint.  It doesn't change any assumption about UTF-16 
usage internally: those assumptions were already in place.  The purpose 
of the change is as Scott stated: it's to improve interoperability and 
allow for the use of UTF-16 character and string literals, and to remove 
platform-specific variation in favour of a single type that's consistent 
across platforms.



Personally, I would absolutely prefer for Xerces-C++ to use UTF-8 in its 
external interfaces and its internal representation.  Like most people, 
I have input in UTF-8, output in UTF-8, and all of the parameters I want 
to pass into Xerces-C++ like element and attribute names, text content 
etc. are UTF-8.  All of this needs transcoding to and from UTF-16.  This 
bears a hugely significant fraction (~50%) of CPU utilisation when I've 
profiled it in the past, and it makes using Xerces-C++ unnecessarily 
painful.  But Xerces-C++ is a product of its time.  Back then, before 
widespread UTF-8 adoption, it was likely seen as forward-looking.  ICU 
and other libraries of the same era are all using UTF-16, or 
Unicode/UCS-2 as it was then.



However, such a change would be massively breaking.  I don't have the 
time or resources to do the work, and even if I did it would be hard to 
justify such a breaking change unless it could be introduced without 
breaking compatibility with the UTF-16 interfaces.  If such a change 
could be made compatibly, I would be in favour of it, but I doubt I 
could spare the required time and effort to do it myself.  I no longer 
get paid to work on Xerces-C++-related projects, and I have a full-time 
job to do which is of much greater priority.  What time I can contribute 
as part of Xerces-C++-using open source project work is limited and as 
such I need to make sure that the work I do is tightly-focussed and 
realistic in its objectives.  The above char16_t work is an example of 
such a change.  It takes great care to avoid a compatibility break (you 
can already opt into it with Xerces-C++ 3.2.x).



If you would like to investigate the changes which would be needed to 
change the internal representation from UTF-16 to UTF-8 and/or 
supplement the external interfaces with UTF-8 alternatives to the UTF-16 
interfaces we have at present, I'm sure we would all be very interested 
to hear your proposals.  As a long-term project goal, I think it would 
be beneficial.  For myself, the question isn't whether the change is 
desirable, it's whether it's realistic and achievable while not breaking 
all the existing projects which have invested time and money into using 
Xerces-C++.  Xerces-C++ has a long history at this point, and breaking 
changes are not something which I think any of us would countenance.  
(The current interfaces do expose some internal details; maybe 
hiding/changing some of them might be justifiable; but certainly not the 
core user-facing APIs.)



Kind regards,

Roger


On 16/07/2020 14:15, Francesco Pretto wrote:

Migrating XMLChar to char16_t basically means setting in stone and
forever that xerces-c is an utf-16 only library so it's going in a
radically different direction than I was suggesting, so I'm not very
happy to hear about it. I think it can be safely stated that this move
actually closes more doors than it opens. While simplifying the code
base and test grid is great, as I'm reading in [1], I would have
chosen to drop support for wchar_t and int16_t but keep XMLChar for
future possibility to support utf8 for internal encoding. Are you really
sure you want to pursue this direction?

[1] https://issues.apache.org/jira/browse/XERCESC-2206



On Thu, 16 Jul 2020 at 14:22, Cantor, Scott  wrote:

On 7/16/20, 8:07 AM, "Francesco Pretto"  wrote:


Thank you, and thank you for frankness! Probably of the two the utf-8
for internal encoding would be more oriented towards c++ modernization
changes, as you said, but probably a big change touching all the code
base.

It's massive. What Roger is doing is making XMLChar work as char16_t. That 
eliminates a lot of problems with literals and STL integration, but it doesn’t 
change the fact that virtually every other C or older C++ library still won't 
integrate well.

-- Scott



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

-
To unsubscribe, e-mail:

3.3.0 Issues migrated to 4.0.0

2020-06-20 Thread Roger Leigh


I moved all the issues using version 3.3.0 to version 4.0.0.

I don't have Jira admin access, so I can't delete the 3.3.0 release 
version, which is no longer in use.



Roger

[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

Re: Proposal for future development of Xerces-C 4.0.0

2020-06-19 Thread Roger Leigh


On 19/06/2020 13:44, Boris Kolpackov wrote:


Hi Roger,

Thanks for getting the ball rolling. See my comments below.

Roger Leigh  writes:


One of the issues I encountered was difficulty in building on modern
platforms, Windows in particular, which was the impetus for developing
the CMake build now incorporated officially in the Xerces-C 3.2.x
releases.

I would suggest we drop support for autotools in 4.0.0. I personally
view both (autotools and CMake) as pretty bad and I don't see a reason
to maintain two bad options.


I wouldn't object to this.  It halves the testing required on Unix 
platforms.  I can't say I adore CMake; it's a big improvement over the 
autotools but still not as nice as I would like, but it serves its 
purpose, and my use of it is primarily pragmatic (I have submitted a 
fair few upstream contributions though, including FindXercesC and 
FindXalanC).



These are too deeply entrenched to consider removing at this point, but
C++11 brings native char16_t and char32_t character types which could
alleviate some of the problems.

Agree. Do you know what's the story with char16_t vs wchar_t on Windows?
Specifically, will (Windows-only) codebases that pass L""-strings to
Xerces-C++ API need to be changed?


They are not directly compatible, but a simple typecast is sufficient to 
convert them.  We already do this in the Win32 transcoder if I recall 
correctly.


I'm not entirely sure how to class code written using L"".  It's not 
really portable, being Windows-only as you say (Windows being the only 
platform where wchar_t is 16-bit and usable as XMLCh). And it's not 
strictly portable even to different builds of Xerces-C, given that XMLCh 
is configurable and that wchar_t isn't even the default (char16_t is the 
default for C++11 and above).


As a result, I think that for any users who are using L"", they would 
have three options:


1. Replace L"" with u"".  This would work with Xerces-C 4.0 and C++11, 
but would not be backward compatible with older Xerces-C versions.


2. Add static_cast() around L"" strings when passing them 
to Xerces-C.  This is portable and works even with older Xerces 
versions, so would be useful as a transitional step for codebases which 
want to support 4.0 and 3.2 and earlier.


3. Add static_cast() around u"" strings when passing them 
to Xerces-C.  As for (2) this provides the same portability to old and 
new versions (it's a no-op when XMLCh is char16_t).  This might be a 
better option when you want to use C++11 but you also need to support 
3.2 and earlier.


So long as we had these clearly documented, I think that would provide 
reasonable guidance and an effective means to transition while retaining 
compatibility with older versions.


Personally, I'd go with (3) for my own projects which are already using 
C++11 and UTF-8-encoded source files and then switch to (1) once all the 
target platforms are using Xerces-C 4.x.



* having exceptions derive from std::runtime_error; existing types can
remain compatible with wide strings

* support use of streams, including stringstreams, directly with Xerces e.g.
InputSource, perhaps as a set of adaptors

* where the C++ language and standard replace functionality in Xerces, it
would be worth considering replacement where there is a benefit; language
thread support might come under this category

Sounds great! If we require C++11 (or later), I see no reason not to
switch to std::thread & friends.


I think here we could also look to Xalan-C for examples.  It has 
historically made use of C++98 features including some support for 
strings, streams etc., and we might be able to directly copy some of its 
implementation choices (providing they make sense).


One of the nice aspects of Xerces-C is that it compiles like greased 
lightning due to not making heavy use of standard library headers.  It 
would be nice to retain that if possible.  We could possibly constrain 
use of streams to specific modules, for example.



On the maintainability side, I'd like to reduce the number of configuration
options to keep testing and support within reason.

Agree. One thing that I would like to keep is the ability to build
Xerces-C++ without any third-party library dependencies.
Yes, I think that point is well made, particularly when it comes to the 
network accessors, transcoders and the like.  There should be a 
self-contained option or none at all as possibilities.

* We have three message loaders and three sets of translations for en_US,
but no other translations. Some or all of them might be worth thinking
about dropping given the complete lack of utility these provide.

To me keeping only ICU and inmemory sounds like the way to go.

Agreed.

* We have several network accessors. But with the modern push for using
HTTPS everywhere, should Xerces be providing its own or should we simply
require CURL or platform-specific functionality?

Ye

Proposal for future development of Xerces-C 4.0.0

2020-06-16 Thread Roger Leigh


Dear all,


To follow up to the suggestion Boris made in the discussion on 
https://issues.apache.org/jira/browse/XERCESC-2204, I would like to 
outline a proposal for the development and release of a version 4.0.0 of 
Xerces-C.  Being a new major version, this would allow co-installation 
with the 3.x library.


Some of the suggested changes already have issues as part of the 3.3.0 
release (https://issues.apache.org/jira/projects/XERCESC/versions/1234)



In using Xerces-C++ for the past 10 years, I have encountered quite a 
few compatibility, usability and performance problems.  Most of these 
can be worked around to some degree, but improving the situation would 
be desirable.  One of the issues I encountered was difficulty in 
building on modern platforms, Windows in particular, which was the 
impetus for developing the CMake build now incorporated officially in 
the Xerces-C 3.2.x releases.



One problem is the use of UTF-16 character strings in our APIs.  They 
are deeply unfriendly to use with typical C++ code, and they also impose 
a performance penalty when the input to Xerces API calls need 
transcoding.  These are too deeply entrenched to consider removing at 
this point, but C++11 brings native char16_t and char32_t character 
types which could alleviate some of the problems.  Depending upon the 
platform and compiler, Xerces-C currently supports various types as 
XMLCh, including unsigned short, uint16_t, wchar_t and char16_t.  With 
C++11, it is possible to use UTF-16 string literals directly with 
u"string", and use these transparently with the Xerces-C API.  While 
this is possible with the 3.2.x releases if you build with char16_t 
support, as an application developer the availability of char16_t 
support in Xerces-C can't be guaranteed.  By making XMLCh char16_t, we 
become directly interoperable with the current C++ language types, 
library features and so on.  It means any application developer can use 
UTF-16 character literals and string literals freely.


An additional benefit of C++11 is the guaranteed availability of 
standard sized integer types.


The change in PR#21 
(https://github.com/apache/xerces-c/pull/21/files#diff-6fc894653e06e51bde4bbba985b1b340R126) 
makes the basic primitive types use C++11 integer types and character 
types.  It remains API compatible with previous Xerces-C releases.


With a switch of XMLCh to char16_t, this would enable direct use of 
unicode string literals.  I have developed a complete switchover here 
(https://github.com/rleigh-codelibre/xerces-c/compare/xerces-XERCESC-2208_Use_cstdint...rleigh-codelibre:XERCESC-2206_unicode_literals?expand=1#diff-5feef1625e289192e9a2d9b2c1a1308bR147) 
but am still proofreading and reviewing the result before I will submit 
it.  This is a complete replacement of most use of XMLUniDefs constants 
in the source tree with C++11 literals. You can see the result is vastly 
more readable and maintainable, and you'll also see in the commit 
messages that I uncovered three separate bugs in the existing strings 
while doing the conversion which I'll fix separately on the 3.2 branch 
after I'm sure there are no other bugs there.  The code of applications 
using Xerces-C becomes similarly more readable.  This one is a bit big 
and intimidating, but almost all the changes were made with search and 
replace with sed or other tools.



On the interoperability side, Xerces has never really integrated well 
with the standard library.  Whether you want to catch exceptions, use 
strings and streams, these all require extra effort to use.  I'd like to 
refactor some of the classes to ease use with applications using the 
standard library.  This includes:


* having exceptions derive from std::runtime_error; existing types can 
remain compatible with wide strings


* support use of streams, including stringstreams, directly with Xerces 
e.g. InputSource, perhaps as a set of adaptors


* where the C++ language and standard replace functionality in Xerces, 
it would be worth considering replacement where there is a benefit; 
language thread support might come under this category



On the maintainability side, I'd like to reduce the number of 
configuration options to keep testing and support within reason.  
Adopting C++11 removes a lot of complexity and configuration variants.  
In addition:


* We have three message loaders and three sets of translations for 
en_US, but no other translations.  Some or all of them might be worth 
thinking about dropping given the complete lack of utility these 
provide.  Does anyone actually use the translation functionality or have 
any message catalogues other than en_US?


* We have several network accessors.  But with the modern push for using 
HTTPS everywhere, should Xerces be providing its own or should we simply 
require CURL or platform-specific functionality?


* Building with a modern compiler or using a modern IDE flags up tens of 
thousands of warnings.  Some can be fixed by

[jira] [Commented] (XERCESC-2208) Rationalise XercesIntTypes

2020-06-13 Thread Roger Leigh (Jira)



[ 
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

2020-06-13 Thread Roger Leigh (Jira)



 [ 
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

2020-06-12 Thread Roger Leigh (Jira)



[ 
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

2020-06-12 Thread Roger Leigh (Jira)



[ 
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

2020-06-11 Thread Roger Leigh (Jira)



[ 
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

2020-06-04 Thread Roger Leigh (Jira)

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

2020-06-03 Thread Roger Leigh (Jira)



 [ 
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

2020-06-03 Thread Roger Leigh (Jira)



 [ 
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

2020-05-29 Thread Roger Leigh (Jira)



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

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

2020-05-24 Thread Roger Leigh (Jira)



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

Re: Xerces-C V3.2.3 released

2020-04-12 Thread Roger Leigh


On 11/04/2020 14:41, Roger Leigh wrote:


On 10/04/2020 17:28, Cantor, Scott wrote:

A patch release of Xerces-C, V3.2.3, is now available. The web site 
[1] and download site are refreshed [2] with the relevant links 
updated. The list of issues addressed can be found at [3].


Hi Scott,

Does archive.apache.org also need updating?  Some URLs used by 
packaging tools e.g.


  url 
"https://www.apache.org/dyn/closer.lua?path=xerces/c/3/sources/xerces-c-3.2.2.tar.gz;
  mirror 
"https://archive.apache.org/dist/xerces/c/3/sources/xerces-c-3.2.2.tar.gz;


Do not work with a 3.2.3 version number substituted.

As well as updating MacOS X homebrew, I've updated Microsoft vcpkg 
(https://github.com/microsoft/vcpkg/pull/10779) and have also updated 
the FreeBSD port (currently testing all the reverse dependencies with 
poudriere before opening the ticket).  I'll also open tickets with 
Debian and Fedora.  Any others to consider?


Note Fedora noted the same problem with the archive URL here: 
https://bugzilla.redhat.com/show_bug.cgi?id=1822963


Ports ticket: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245576

Once the archive URL is fixed, I'll do the homebrew update.


Regards,

Roger


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

Re: Xerces-C V3.2.3 released

2020-04-11 Thread Roger Leigh


Hi Bill,


That's much appreciated, thanks.


Thanks,

Roger

On 11/04/2020 19:07, Bill Blough wrote:

Re: the Debian package for Xerces-C

I expect to upload the updated package to Debian before the end of the
weekend, so you can skip filing a bug there, if you'd like.

Best regards,
Bill

On Sat, Apr 11, 2020 at 02:41:31PM +0100, Roger Leigh wrote:

On 10/04/2020 17:28, Cantor, Scott wrote:


A patch release of Xerces-C, V3.2.3, is now available. The web site [1] and 
download site are refreshed [2] with the relevant links updated. The list of 
issues addressed can be found at [3].

Hi Scott,

Does archive.apache.org also need updating?  Some URLs used by packaging
tools e.g.

   url 
"https://www.apache.org/dyn/closer.lua?path=xerces/c/3/sources/xerces-c-3.2.2.tar.gz;
   mirror
"https://archive.apache.org/dist/xerces/c/3/sources/xerces-c-3.2.2.tar.gz;

Do not work with a 3.2.3 version number substituted.

As well as updating MacOS X homebrew, I've updated Microsoft vcpkg
(https://github.com/microsoft/vcpkg/pull/10779) and have also updated the
FreeBSD port (currently testing all the reverse dependencies with poudriere
before opening the ticket).  I'll also open tickets with Debian and Fedora.
Any others to consider?


Regards,

Roger


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

Re: Xerces-C V3.2.3 released

2020-04-11 Thread Roger Leigh


On 10/04/2020 17:28, Cantor, Scott wrote:


A patch release of Xerces-C, V3.2.3, is now available. The web site [1] and 
download site are refreshed [2] with the relevant links updated. The list of 
issues addressed can be found at [3].


Hi Scott,

Does archive.apache.org also need updating?  Some URLs used by packaging 
tools e.g.


  url 
"https://www.apache.org/dyn/closer.lua?path=xerces/c/3/sources/xerces-c-3.2.2.tar.gz;
  mirror 
"https://archive.apache.org/dist/xerces/c/3/sources/xerces-c-3.2.2.tar.gz;


Do not work with a 3.2.3 version number substituted.

As well as updating MacOS X homebrew, I've updated Microsoft vcpkg 
(https://github.com/microsoft/vcpkg/pull/10779) and have also updated 
the FreeBSD port (currently testing all the reverse dependencies with 
poudriere before opening the ticket).  I'll also open tickets with 
Debian and Fedora.  Any others to consider?



Regards,

Roger


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

Re: CI testing of Xerces-C

2020-04-06 Thread Roger Leigh




On 06/04/2020 13:28, Cantor, Scott wrote:

On 4/6/20, 8:24 AM, "Roger Leigh"  wrote:


It should be pretty simple for any Apache contributor to push any
potential update as a feature branch to GitBox and then check the CI run
passes, prior to merging to an integration branch.  This will ensure
that no regressions should be present on an integration branch.

I see the value (depending on the actual complexity of the change), but I'm not 
sure what access rules are in place around branches (e.g. can people delete 
them? push non-ff updates?), and having a giant accumulating pile of feature 
branches is its own problem, so that's what I meant by us not really having a 
clear set of policies around it.


You can simply delete the branch once you're done with it.  With GitHub, 
you can delete the branch on PR merge (and it's also gating merge on CI 
tests passing).  With GitBox, you would have to manually merge and then 
delete the feature branch.  I'd certainly recommend deleting them to 
avoid the unnecessary clutter of stale branches building up over time.


You probably saw the notifications for the ci-test branch I used earlier 
today to trigger the test runs of the current master and xerces-3.2 
branches.  I simply pushed :ci-test to delete it once the runs were 
completed.


Regards,

Roger


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

Re: CI testing of Xerces-C

2020-04-06 Thread Roger Leigh


On 06/04/2020 12:42, Cantor, Scott wrote:


On 4/6/20, 7:21 AM, "Roger Leigh"  wrote:


  You can simply push your feature branch and wait for the tests to pass before 
merging to and pushing the integration
branch.

I'm not sure that there's been adequate discussion of any actual development 
process for using git, or any policies put in place about how to deal with 
feature branches.

But that aside are you saying every branch is automatically being built and 
tested?


Hi Scott,


Yes, every GitHub branch update will trigger a CI run.  This includes 
all branch updates to GitBox since they are mirrored to GitHub.  The 
branch update can be by any possible means: direct push of a branch to 
GitHub, indirectly via a push to GitBox, or opening/updating/merging a PR.


We had all this in place last year, but when we switched over to git, 
the CI integrations (which belonged to the old mirror of the SVN 
repository) were lost and needed re-enabling for the new repository.


It should be pretty simple for any Apache contributor to push any 
potential update as a feature branch to GitBox and then check the CI run 
passes, prior to merging to an integration branch.  This will ensure 
that no regressions should be present on an integration branch.



Regards,

Roger


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

CI testing of Xerces-C

2020-04-06 Thread Roger Leigh


Dear all,


CI testing was present prior to the switch from SVN to GitBox, but 
needed re-enabling by Infra for the new repository.  It's re-enabled 
since yesterday (see INFRA-20073), and both the xerces-3.2 and master 
branch are passing for both Travis and AppVeyor:


https://github.com/apache/xerces-c/tree/xerces-3.2

https://github.com/apache/xerces-c/tree/master

Hopefully this will give additional confidence that the upcoming release 
has adequate test coverage and that no regressions have occurred since 
the previous CI testing ceased.


Both branches will continue to run CI tests for all subsequent pushes to 
GitBox, GitHub or via GitHub pull request merges.  If you're not using 
GitHub directly, a push to GitBox will trigger the tests as soon as the 
branch is automatically synced with GitHub.  You can simply push your 
feature branch and wait for the tests to pass before merging to and 
pushing the integration branch.



Kind regards,

Roger

[jira] [Resolved] (XERCESC-2176) Incorrect symbolic links created for Linux static library and MacOS static and shared libraries

2020-04-03 Thread Roger Leigh (Jira)



 [ 
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

2020-04-02 Thread Roger Leigh (Jira)



[ 
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

2020-04-02 Thread Roger Leigh (Jira)



[ 
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

2020-04-02 Thread Roger Leigh (Jira)



[ 
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