Re: Xerces-C V3.2.5 now available

[Boris Kolpackov]

Cantor, Scott  writes:

> The Xerces project has released V3.2.5 of the C++ parser library [...]

Thanks for making the release and doing all the administrative stuff!

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

Re: Release candidate for V3.2.5 patch

[Boris Kolpackov]

Cantor, Scott  writes:

> I suggest we wait until next Wednesday and close the vote
> that morning. I should be able to complete the release and
> check in the site updates that day.

Sounds good to me, thanks!


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

Re: Release candidate for V3.2.5 patch

[Boris Kolpackov]

Cantor, Scott  writes:

> Windows has not yet been tested.

I've built and tested using standard CMake/ninja instructions in
both debug and release build types with MSVC 17.6 (19.36.32534).
No errors, all tests passed.


> If Windows builds, this would be the candidate to vote out.

My +1 for the release.

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

[jira] [Commented] (XERCESC-2188) Use-after-free on external DTD scan

[Boris Kolpackov (Jira)]

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

Boris Kolpackov commented on XERCESC-2188:
--

A new PR with the fix: [https://github.com/apache/xerces-c/pull/54]

Please review/test.

> Use-after-free on external DTD scan
> ---
>
> Key: XERCESC-2188
> URL: https://issues.apache.org/jira/browse/XERCESC-2188
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Validating Parser (DTD)
>Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0, 3.1.1, 3.1.2, 3.2.0, 3.1.3, 
> 3.1.4, 3.2.1, 3.2.2
>Reporter: Scott Cantor
>Priority: Major
> Attachments: Apache-496067-disclosure-report.pdf
>
>
> This is a record of an unfixed bug reported in 2018 in the DTD scanner, per 
> the attached PDF, corresponding to CVE-2018-1311.



--
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: C++ Class Generation Based off .xsd Files

[Boris Kolpackov]

Thomas Ranneberger  writes:

> I am attempting to take provided .xsd files that detail the xml schema
> definitions of certain message types, and turn these into C++ classes
> for sending messages and validating those message fields. Does this
> sound like something Xerces is capable of doing?

There is a tool called XSD (built on top of Xerces-C++) that does this:

https://codesynthesis.com/products/xsd/

-
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

[Boris Kolpackov]

Cantor, Scott  writes:

> I am open to either doing a patch at some point after a little
> time elapses or officially moving the code base to C++-11.

I would prefer to move to C++11. If nobody cares, why create
unnecessary churn by making another release?

I propose the following plan:

1. Wait a bit more to see if anyone complains.

2. If nobody complains, then formalize with a vote the move
   to C++11 and add a note to this effect to the release notes
   on the website.

-
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

[Boris Kolpackov]

Cantor, Scott  writes:

> I've patched the use of nullptr out simply for consistency but there's
> no apparent need to rush out a fix, so I'll let it sit for the time
> being.

I don't mind waiting (to see if anything else shakes out) but I think
we either need a bugfix release eventually or officially drop support
for C++98/03. I don't mind the latter and would vote for it.

-
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

[Boris Kolpackov]

Roger Leigh  writes:
 
> 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.

nullptr was added in C++11 so by using it you effectively drop
support for C++98/03. I personally don't mind dropping this
support but I think it should be a bit more formal than "ops, 
we just dropped C++98/03 accidentally". I.e., a vote and a
note in the release notes would be a good idea.

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

Re: 3.2.4 release candidate

[Boris Kolpackov]

Cantor, Scott  writes:

> On 10/12/22, 9:09 AM, "Boris Kolpackov"  wrote:
> 
> >2. We build with ICU and Curl everywhere so other transcoders
> >   and netaccessors were not tested.
> 
> Do you actually use them? Because in my testing, I haven't managed to
> make any of the net accessors work (per the open bug that was reported).

We run NetAccessorTest.cpp on every platform and it seems to work, at
least over HTTP (HTTPS would require some further patching to deal with
CA paths setup on some platforms):

$ ./libxerces-c/tests/net-accessor/driver http://www.example.org

...
Example Domain
...

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

Re: 3.2.4 release candidate

[Boris Kolpackov]

Cantor, Scott  writes:

> I've posted a signed RC here:
> https://dist.apache.org/repos/dist/dev/xerces/c/3/sources/

We've updated our build2 package[1] to RC1 and ran the CI. Everything
seems to be fine except for the wasm32-emscripten target, which is
not unexpected. The complete list of tested configurations/targets
is below and you can see the details on this page:

https://ci.stage.build2.org/@8dca6161-e2d9-491b-bd85-34eef3fa64f7

So here is my +1 vote for the release.

A couple of notes:

1. This is using the build2 build system so neither CMake nor
   Autoconf support was tested.

2. We build with ICU and Curl everywhere so other transcoders
   and netaccessors were not tested.

3. We apply a few patches, mostly build-related fixes (see the
   README-DEV file for details).

4. We only run a subset of tests/examples.

5. All the tested targets are 64-bit (except WASM).

linux_debian_8-gcc_4.9   x86_64-linux-gnu
linux_debian_9-gcc_7.4   x86_64-linux-gnu
linux_debian_9-gcc_8.4   x86_64-linux-gnu
linux_debian_10-gcc_9.3  x86_64-linux-gnu
linux_debian_10-gcc_10.2 x86_64-linux-gnu
linux_debian_11-gcc_11.3 x86_64-linux-gnu
linux_debian_11-gcc_12.1 x86_64-linux-gnu
linux_debian_11-gcc_12.1-O3  x86_64-linux-gnu
linux_debian_11-gcc_12.1-static_O3   x86_64-linux-gnu
linux_debian_11-gcc_12.1-ndebug_O3   x86_64-linux-gnu
linux_debian_11-gcc_12.2 aarch64-linux-gnu
linux_ubuntu_16.04-clang_3.7_libc++  x86_64-linux-gnu
linux_debian_9-clang_6.0 x86_64-linux-gnu
linux_debian_9-clang_6.0_libc++  x86_64-linux-gnu
linux_debian_9-clang_7.0 x86_64-linux-gnu
linux_debian_9-clang_7.0_libc++  x86_64-linux-gnu
linux_debian_9-clang_8.0 x86_64-linux-gnu
linux_debian_9-clang_8.0_libc++  x86_64-linux-gnu
linux_debian_10-clang_9.0x86_64-linux-gnu
linux_debian_10-clang_9.0_libc++ x86_64-linux-gnu
linux_debian_10-clang_10.0   x86_64-linux-gnu
linux_debian_10-clang_10.0_libc++x86_64-linux-gnu
linux_debian_10-clang_11.0   x86_64-linux-gnu
linux_debian_10-clang_11.0_libc++x86_64-linux-gnu
linux_debian_10-clang_12.0   x86_64-linux-gnu
linux_debian_10-clang_12.0_libc++x86_64-linux-gnu
linux_debian_11-clang_13.0   x86_64-linux-gnu
linux_debian_11-clang_13.0_libc++x86_64-linux-gnu
linux_debian_11-clang_14.0   x86_64-linux-gnu
linux_debian_11-clang_14.0-O3x86_64-linux-gnu
linux_debian_11-clang_14.0-static_O3 x86_64-linux-gnu
linux_debian_11-clang_14.0_libc++x86_64-linux-gnu
linux_debian_11-clang_14.0_libc++-O3 x86_64-linux-gnu
linux_debian_11-clang_14.0_libc++-static_O3  x86_64-linux-gnu
linux_debian_11-clang_14.0   aarch64-linux-gnu
linux_debian_11-clang_14.0_libc++aarch64-linux-gnu
macos_11-clang_13.0  x86_64-apple-darwin20.5.0
macos_12-clang_13.1  x86_64-apple-darwin21.6.0
macos_12-clang_13.1-O3   x86_64-apple-darwin21.6.0
macos_12-clang_13.1-static_O3x86_64-apple-darwin21.6.0
macos_12-gcc_12.1_homebrew   x86_64-apple-darwin21.6.0
macos_12-gcc_12.1_homebrew-O3x86_64-apple-darwin21.6.0
macos_12-gcc_12.1_homebrew-static_O3 x86_64-apple-darwin21.6.0
freebsd_11-clang_10.0x86_64-unknown-freebsd11.4
freebsd_12-clang_10.0x86_64-unknown-freebsd12.3
freebsd_13-clang_13.0x86_64-unknown-freebsd13.1
freebsd_13-clang_13.0-O3 x86_64-unknown-freebsd13.1
freebsd_13-clang_13.0-static_O3  x86_64-unknown-freebsd13.1
windows_10-gcc_12.2_mingw_w64x86_64-w64-mingw32
windows_10-gcc_12.2_mingw_w64-O2 x86_64-w64-mingw32
windows_10-gcc_12.2_mingw_w64-static_O2  x86_64-w64-mingw32
windows_10-msvc_14.3 x86_64-microsoft-win32-msvc14.0
windows_10-msvc_15.9 x86_64-microsoft-win32-msvc14.1
windows_10-msvc_16.11x86_64-microsoft-win32-msvc14.2
windows_10-msvc_16.11-O2 x86_64-microsoft-win32-msvc14.2
windows_10-msvc_16.11-static_O2  x86_64-microsoft-win32-msvc14.2
windows_10_devmode-msvc_16.11x86_64-microsoft-win32-msvc14.2
windows_10-msvc_17.2 x86_64-microsoft-win32-msvc14.3
windows_10-msvc_17.2-O2  

Re: 3.2.4 release candidate

[Boris Kolpackov]

Cantor, Scott  writes:

> On 10/11/22, 10:28 AM, "Boris Kolpackov"  wrote:
> 
> >Remind me where does the source for the front page live?
> 
> doc/readme.xml I think (it's in doc, but page is from memory, should
> be clear from the commit).

That's what I thought but I don't see any commits in the history that
add your original note.


> >FWIW, we have a commercial product based on Xerces-C++ and if any
> > of its users report bugs in Xerces-C++, we will work on fixing them.
> 
> This is a public list, so I'm comfortable pointing to this thread
> should any complaints arise and am ok changing the wording for now.

Sure. To make sure there is no misunderstanding, by "its users" in the
above sense I mean users of our "commercial product based on Xerces-C++".
But, generally, I will try to help out more where I can.

-
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

[Boris Kolpackov]

Cantor, Scott  writes:

> On 10/10/22, 12:17 PM, "Boris Kolpackov"  wrote:
> 
> >Not every application that uses Xerces-C++ is security sensitive.
> 
> If that were our perspective as a project, then among other things
> there should be no networking code in there.

FWIW, in the Xerces-C++ package that I linked to earlier networking
is disabled by default. But it's also possible that networking is safe,
for example if the application is running on the secure network.

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

Re: 3.2.4 release candidate

[Boris Kolpackov]

Cantor, Scott  writes:

> Done, v3.2.4rc1.

Thanks!


> > The web site update embedded in it includes a note on the front page
> > that the library lacks maintainers and should not be used for new
> > projects. Are we talking about this change or something else?
> 
> I changed both the front page and the release plan page. I did the
> latter before the former, so they are slightly different in tone,
> but the important note is the one on the front page.

Remind me where does the source for the front page live?

Looking at the doc/html/index.html in the archive I assume this is
the addition:

"PLEASE NOTE: Xerces-C++ lacks maintainers and is in a largely legacy
 state. We do not recommend its adoption by new projects, and encourage
 those still using it to explore alternatives."

If so, I would be against this wording. As I believe was clearly
demonstrated by the discussion in this thread, there are no suitable
alternatives for some functionality provided by Xerces-C++, specifically,
mature, battle-tested XML Schema support.

I would be Ok with the following statement of facts (rather than telling
people what they should and should not do):

"Please note that the Xerces-C++ project currently lacks active maintainers
and therefore may not be able to promptly address bugs and security 
vulnerabilities."

FWIW, we have a commercial product based on Xerces-C++ and if any of its
users report bugs in Xerces-C++, we will work on fixing them.

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

Re: 3.2.4 release candidate

[Boris Kolpackov]

Cantor, Scott  writes:

> I've posted a signed RC here:
> https://dist.apache.org/repos/dist/dev/xerces/c/3/sources/

Thanks for your work on this!

The corresponding git branch is xerces-3.2 and the commit is
bfe32a149e8c ("Adjust release info."), correct? Wouldn't be
bad to tag the RC to make sure we are testing the same thing.


> The web site update embedded in it includes a note on the front page
> that the library lacks maintainers and should not be used for new
> projects.

Are we talking about this change or something else?

- There has been some discussion of incorporating some improvements and 
modernizing the code base a bit in 3.3.0 release.
+ There had been some discussion of incorporating some improvements and 
modernizing the code base a bit in a 4.0.0 release but there are no committers 
available with the interest in doing this work. At this time, no further 
releases are planned.

-
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

[Boris Kolpackov]

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. I did a bit
of searching now and the best documentation I could find is this man
page, which still says it is incomplete:

https://gnome.pages.gitlab.gnome.org/libxml2/devhelp/libxml2-xmlschemas.html


> It is hardly unusual to find that the best option to do something in
> C++ is to use a C library.

I don't know, in this case Xerces-C++ support and especially documentation
look miles ahead.


> >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. We are
also packaging Expat and it's a constant stream of CVEs. And if you
think since it's actively maintained (which it is), those CVEs are
promptly patched, you are mistaken again: it's pretty common for the
release to appear weeks after the CVEs is fixed in the repository.

-
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

[Boris Kolpackov]

Roger Leigh  writes:

> If Xerces-C++ was to be retired, projects will need to consider other
> options, be that other libraries, or other languages.

What would be the other options for XML Schema validation usable from C++?

It's easy to say people should do this and that in the abstract. Given a
C++ codebase that needs to parser XML with XML Schema validation, what
concrete steps do you propose people take to migrate to something else?
And, no, rewriting everything in a different language just because
Xerces-C++ has some bugs is not a sensible step.

FWIW, I will vote strongly against moving Xerces-C++ to Attic and if
that happens we will fork it (we are already half way there[1] anyway).

[1] https://github.com/build2-packaging/xerces-c

-
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

[Boris Kolpackov]

Cantor, Scott  writes:

> Were it my decision, I would post a warning that the code is being
> sunsetted and anybody on it should be getting off it.

Getting off to what? Xerces-C++, with all its warts, is the only working,
open source XML Schema implementation for C/C++. And I know for a fact
that it is being used without much problems by quite a few people.

What I think would be reasonable to state is that the project, due to
limited resources, may not be able to promptly fix bugs and security
vulnerabilities.


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

I would be happy to CI a release candidate on our setup[1]. It covers
all the major platforms and compiler combinations (currently 60+ build
configurations). Just ping me with the branch/commit when it's ready.

[1] https://ci.cppget.org/?build-configs

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

Re: Xerces-C++ 3.2.4

[Boris Kolpackov]

Roger Leigh  writes:

> Would it be possible to add 3.2.4 as a new unreleased version in Jira?

Done.


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

Sounds good. Is Even finished with everything they wanted to fix?


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

Nothing from my side. We have a bunch of warnings and a failure to
build with Emscripten on our CI[1] but unfortunately no bandwidth
to look into any of it at the moment.


[1] https://queue.stage.build2.org/?builds=libxerces-c

-
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

[Boris Kolpackov]

Roger Leigh  writes:

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

>From experience dealing with clients, there are applications that only
need to target Windows and they use L"" strings liberally.

Still, I think the benefits of switching to char16_t outweighs this
drawback.


> These both make sense. For the networking side, I think we could also argue
> the case for the MacOS accessor as well (cfurl), so long as it supports
> SSL.

The problem with MacOS-specific accessor is that I believe it requires
linking a framework which make things messy (static linking on user side,
pkg-config, etc). But if there is strong desire to have it, I am fine
with that, especially if the default is "no network".


> >In another project I am working on (build2) we had good results with
> >picking GCC 4.9, Clang 3.7, and MSVC 14u3 and getting a very usable
> >subset of C++14 (including move capture and generic lambdas).
>
> I'm on slightly more recent versions, as is the AppVeyor and Travis CI, but
> so long as we can agree on the required C++ subset we can identify the
> minimum version requirement.

That would probably require quite a bit of effort. As in, are we going
to create a document listing every C++11/14 feature we are allowed to
use (with some of them having multiple semantic revisions)?

In this sense picking the minimum versions of the three major compilers
and saying that any commit that compiles and works with these is fair
game is a lot simpler and crispier criterion. Though that would mean we
need to have these versions always available for CI (not sure how doable
that is with AppVeyor and/or Travis CI).


> >Another issue that we will need to decide on is which standard we
> >are going to build for (at least by default) and whether we will
> >be making it configurable. The problem here is that there is no
> >guarantee that code built for different standards is ABI-compatible
> >(and there are cases where the C++ standard itself broke this
> >compatibility). As a result, the only sure way to avoid surprises
> >is to build everything (Xerces-C++ and the application that uses
> >it) for the same standard.
> >
> >For example, in build2 by default we use the latest available
> >standard for any given compiler/version but there is also a way to
> >override it for the entire build configuration. I am not sure if
> >CMake has anything like this.
> 
> It does, see https://cmake.org/cmake/help/latest/prop_tgt/CXX_STANDARD.html
> 
> We currently have it set like this:
> https://github.com/apache/xerces-c/blob/master/CMakeLists.txt#L37 :
> 
># Try C++17, then fall back to C++14, C++11 then C++98.  Used for
>feature tests
># for optional features.
>set(CMAKE_CXX_STANDARD 17)
> 
> CMAKE_CXX_STANDARD sets the requested standard version.  If unavailable, it
> will fall back to earlier standards.  Since Xerces-C++ doesn't have a
> minimum standard at present, we allow it to fall back without restriction
> and then do specific feature tests to see what's available.  If we require
> C++14, we will need to add
> 
>set(CMAKE_CXX_STANDARD 17)
> 
>set(CMAKE_CXX_STANDARD_REQUIRED ON)
> 
> in order to mandate C++14. It will then fail if it is not possible to
> achieve this.

You probably meant to write `set(CMAKE_CXX_STANDARD 14)` here, right?


> What I do in my projects is something like this:
> 
># Prefer C++17 support
>if(NOT CMAKE_CXX_STANDARD)
>set(CMAKE_CXX_STANDARD 17)
>set(CMAKE_CXX_STANDARD_REQUIRED FALSE)
>endif()
> 
> This is to permit the user to override it, and only default if unset.

There is no special `latest` value or some such for CMAKE_CXX_STANDARD?

If not, I guess something like this will have to do:

if(NOT CMAKE_CXX_STANDARD)
  set(CMAKE_CXX_STANDARD 20)
  set(CMAKE_CXX_STANDARD_REQUIRED FALSE)
endif()

We will then have to keep updating it to make sure Xerces-C++ is compatible
with the latest standard.

-
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

[Boris Kolpackov]

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.


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


> With a switch of XMLCh to char16_t, this would enable direct use of unicode
> string literals. [...] This is a complete replacement of most use of
> XMLUniDefs constants in the source tree with C++11 literals.

Sounds great!


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


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


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



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

Yes, I believe there should be only two options: no network support and
CURL.

There are also several transcoder options. Again, I think we should
only keep the built-in stuff and ICU.


> * Building with a modern compiler or using a modern IDE flags up tens of
> thousands of warnings. Some can be fixed by using features like "mutable"
> which previously were not universally available. It would be worth running
> the codebase through clang-format and clang-tidy to clean it up stepwise.
> It could well fix quite a few bugs and help improve performance and
> correctness.

Don't think anyone will object to that.


> Finally, I should note that while the above might look quite disruptive, I'm
> not suggesting any sort of API breakage at this point.

I agree. I think we should be mindful of migration efforts that will be
required on the user's side.

Another thing worth discussing is which C++ standard we should target. I
think at a minimum C++11 but perhaps we should be bold and aim a bit
higher?

In fact, IMO, talking about targeting a C++ standard like C++11 or C++14
is not very useful since every major C++ compiler (GCC, Clang, MSVC)
completes support for the next standard over multiple releases. As
a result, while compilers may not have complete support, they often
include a perfectly usable subset of the features.

In this light, what we found more useful is to specify the minimum
versions of the three major compilers that we are willing to support
and any features that are available in all three are fair game.

In another project I am working on (build2) we had good results with
picking GCC 4.9, Clang 3.7, and MSVC 14u3 and getting a very usable
subset of C++14 (including move capture and generic lambdas).

Another issue that we will need to decide on is which standard we
are going to build for (at least by default) and whether we will
be making it configurable. The problem here is that there is no
guarantee that code built for different standards is ABI-compatible
(and there are cases where the C++ standard itself broke this
compatibility). As a result, the only sure way to avoid surprises
is to build everything (Xerces-C++ and the application that uses
it) for the same standard.

For example, in build2 by default we use the latest available
standard for any given compiler/version but there is also a way to
override it for the entire build configuration. I am not sure if
CMake has anything like this.

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

[jira] [Commented] (XERCESC-2204) Remove message loader

[Boris Kolpackov (Jira)]

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

Boris Kolpackov commented on XERCESC-2204:
--

I think it's pretty clear iconv is redundant but it would be bad to loose the 
ability to build an external dependency-free version of Xerces-C++.

 

Perhaps we should have a thread on c-dev to discussing and agree on the plan 
for 4.0.0 where we can also consider removing other redundant components, 
switching to a later C++11 standard, etc? Roger, if you could maybe send the 
list all the major changes you have in mind, this will get the ball rolling?

> 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-2204) Remove message loader

[Boris Kolpackov (Jira)]

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

Boris Kolpackov commented on XERCESC-2204:
--

I am not sure about this. While we do not provide translations ourselves, I 
believe at least with ICU they can be loaded dynamically. In other words, there 
could be applications out there relying on that functionality (or, admittedly 
less realistically, there could be application that will want this 
functionality in the future – internationalization is often an afterthought).

Secondly, I believe such a change would require a new major release (since it 
won't be source-compatible) and probably a vote. More generally, I've seen a 
few other bug reports from you (e.g., requiring std::mutex) that I believe 
would require 4.0.0. So I am wondering what's the overall goal here? Are you 
signing up to modernize Xerces-C++ ;)?

> 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

Re: Xerces V3.2.3 release candidate - call for vote

[Boris Kolpackov]

+1

Thanks!

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

Re: Xerces-C 3.2.3 timeline

[Boris Kolpackov]

Cantor, Scott  writes:

> I have external constraints such that if I'm going to do this patch release
> it needs to be done next week, so any remaining work would need to be in
> this week so I can do a build for vote early next.
>
> There is nothing I would expect is getting done that I think is essential so
> I'm not asking for anything, just a heads up in case somebody wants to do
> something. Of course if somebody else wants to do a release later, that's
> fine also.

Sounds good to me. Nice bug cleaning spree!

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

Re: Branching for 3.3 work?

[Boris Kolpackov]

Cantor, Scott  writes:

> On 3/6/20, 9:56 AM, "Boris Kolpackov"  wrote:
> 
> > I am not aware though from the names internal/ and dom/impl/ should be
> > off-limits while everything else is probably fair game.
> 
> I'm happy if we decide we just say that since it addresses this
> particular case, but names aside I don't think there was a formal
> page saying it. If we agree on that, I can do an update the release
> policy material to expand it to "Versioning and API policy".

Sounds good to me. I, personally, think we don't even need a vote
for this. Maybe if you don't hear any opposing views, just make the
change?

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

Re: Branching for 3.3 work?

[Boris Kolpackov]

Cantor, Scott  writes:

> I may have mispoke in that issue too: is there any formal definition of
> which include directories are "API" and which should be off limits for
> library clients?

I am not aware though from the names internal/ and dom/impl/ should be
off-limits while everything else is probably fair game.


> I'm not aware of any such documentation so my impression is compatibly
> changing any callable or inheritable API (thus the ABI) would be a minor
> bump.

The documentation is in "What are the release policies for Xerces-C++?":

https://xerces.apache.org/xerces-c/faq-contributing-3.html#faq-2

In summary, patch releases are ABI-compatible, minor -- API compatible
but not necessarily ABI-compatible (thus dependents must be recompiled),
and major are API-breaking.

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

Re: Branching for 3.3 work?

[Boris Kolpackov]

Cantor, Scott  writes:

> Normally I wouldn't be keen to branch now if the next patch was to 3.2,
> but because the changes are so minimal now, maintaining patches to two
> branches would not be very much work.

Ok, makes sense, thanks.

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

Re: Branching for 3.3 work?

[Boris Kolpackov]

Cantor, Scott  writes:

> There's an open bug or two that probably would need to lead to an API bump
> from 3.2 and the suggestion was made that even if we may not have a ton of
> active effort, there may be value in allowing such work to occur if the
> cycles to do it happen to be available.
>
> I don't have any problems personally with agreeing to apply the small number
> of changes that are likely to both branches in the interim, so I'm fine
> branching 3.2 off for maintenance and leaving master for other work if the
> rest of the PMC doesn't object.

Just to confirm my understanding, you would like to create the 3.2-series
branch in order to release 3.2.3 with some cherry-picked commits, correct?

If so, I am wondering why not instead go ahead and release master as 3.3?

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

[ANN] Xerces-C++ has switched to Git

[Boris Kolpackov]

The Xerces-C++ project has switched to Git and I have asked Infra to mark
everything under https://svn.apache.org/repos/asf/xerces/c/ as read-only.

As discussed, the two new repositories are:

  xerces-c.git
  xerces-c-admin.git
 
You can use either the Apache GitBox:

  https://gitbox.apache.org/repos/asf?p=  (browse)
  https://gitbox.apache.org/repos/asf/(clone)

Or GitHub:

  https://github.com/apache/  (both)

Roger, could you please merge your .gitignore/.gitattributes PR?

Scott, do you think you can update the "Source Repository" page
in the website repo (still uses SVN; I think you are the last
one to deal with it and so probably have a good idea what to do):

  https://xerces.apache.org/xerces-c/source-repository.html

Thanks to everyone for your help and patience.

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

Re: Git migration [PLEASE READ]

[Boris Kolpackov]

Roger Leigh  writes:

> I've opened an initial pull request on GitHub here:
> https://github.com/apache/xerces-c/pull/1
> 
> I didn't see Scott on GitHub, so I added Boris as a reviewer. This change is
> basically to ensure that we have sanity in line ending conventions when
> making changes with contributors from different platforms, as well as
> properly excluding generated content from accidentally being added under
> source control. I wanted to get this initial change in before starting to
> make any further changes with git.
> 
> Are these changes generally acceptable?

Yes, they are very much needed and appreciated, thanks for jumping in
on this.

The PR looks good to me but before we proceed we need to "officially"
switch to Git and mark SVN read-only.

Let's take another 24 hours and if I don't hear any objections or
requests for more time, I am going to ask Infra to mark SVN read-
only at which point Git will be open for business.


> We previously had Travis and AppVeyor CI testing working with the old GitHub
> repository. Would it be possible to re-enable them for the new repository?

When I tried to create the xerces-c.git repository in Apache GitBox I
couldn't because of this mirror. The options (according to Infra) were
to kill it or use it as the starting point. I asked the infra to kill it
since it was out-of-date and also I didn't perform any verifications on
it.

Sorry if this also killed some CI integration. If you know how to re-
enable it, I have no objections (I doubt anyone else would).

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

Re: Git migration

[Boris Kolpackov]

Cantor, Scott  writes:

> It's just https://gitbox.apache.org/repos/asf/reponame.git

Got it, thanks.

Are you all setup for write access to xerces-c.git? Can you maybe
push and delete a test branch just to confirm?

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

Re: Git migration

[Boris Kolpackov]

I've created the xerces-c.git repository and pushed the conversion
result with the latest changes:

https://gitbox.apache.org/repos/asf?p=xerces-c.git

https://github.com/apache/xerces-c.git

If everyone is happy, I can ask Infra to mark the SVN repository
read-only (until that happens, please treat the Git repository
read-only so that we don't commit in both places).

A bit of heads-up on the Git access: you can either do it via GitHub
or via the Apache GitBox (so it's a mirror with both sides writable).

I didn't try the GitBox way (nor could I find the URL to clone via
this method). 

For GitHub access, you will need to link your Apache account with
your GitHub account as described here:

https://gitbox.apache.org/setup/

Once this is done, I was able to push to the repository. Note that
some steps take several hours to "activate".

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

Re: Git migration

[Boris Kolpackov]

Vincent Ulitzsch  writes:

> Bhargava and I sent a PR your way using this new git:
> https://github.com/boris-kolpackov/xerces-c/pull/1
> However, it seems to me that the new git might not be the right place
> for this PR.

Correct, this is a temporary repository that I published for everyone
to check the SVN to Git migration.


> Where would I create such a PR, given that the SVN situation is a
> little bit unclear right now?

I would suggest that you wait until the migration is complete (as
will be evident from the posts on this mailing list). Once this is
done, it will hopefully be clear what the best place for this PR is.

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

Re: Git migration

[Boris Kolpackov]

Cantor, Scott  writes:

> On 12/20/19, 4:21 AM, "Boris Kolpackov"  wrote:
> 
> > Wouldn't checking out corresponding tags from Git and SVN and then
> > running diff on the directories (ignoring .git/ and .svn/) be
> > sufficient?
> 
> Yes, either way.

Ok, I went through this exercise for trunk as well as the 3.2.2,
3.1.4, 3.0.1, and 2.8.0 tags. There are two classes of differences:

1. Empty directories (created by SVN, ignored by Git).

   I think this is an improvement.

2. $Id$ expansion.

   There is a way to get a similar behavior (but not the same) with
   Git but that would require committing .gitattributes into every
   branch/tag.

   Also, the consensus seems to be that this is a bad idea (Linus
   calls it "totally idiotic" ;-)).

   So my preference would be to leave things as is (i.e., no
   expansion) and maybe clean $Id$ strings out later (we also
   have a few "CVS $Revision$ $Date$" anachronisms).

   For quick background on this (as well as what "not the same" above
   exactly means), see:
   
   
https://stackoverflow.com/questions/384108/moving-from-cvs-to-git-id-equivalent
   
https://stackoverflow.com/questions/1792838/how-do-i-enable-the-ident-string-for-a-git-repository

Other than that, the copies are identical.

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

Re: Git migration

[Boris Kolpackov]

Cantor, Scott  writes:

> I don't know enough to say what the cherry-pick warnings mean, [...]

I did a bit of googling on this one and it appears to be harmless.


> For us it took weeks of time over months to get it right, but we don't
> have that kind of time.

Right. I did spend a couple of days on this interspersed with 24h+
re-fetches of the whole history. So some pain and frustration has
been experienced, if that's what you are looking for ;-)


> The one issue I did see right away is that the old tags all get
> turned into a stubby branches, which we worked around in our
> conversion, but I asked and it's apparently not trivial to fix,
> so probably not worth it here unless others care strongly.

Yes, apparently SVN tags are full branches (whatever that means).
In particular, the tag commits are not part of the trunk history.
So I've created a corresponding Git branch for each SVN tag and
then Git-tagged the tip of each branch. The nice thing about this
approach is that the complete commit history is preserved so if
later anyone wants to do some more advanced surgery on this, they
have all the parts.


> Eyeballing it looks sound, but I think we need to do some selective
> "make dist"s on the tags and do some file comparisons, aside from
> the autotools files that will be different by definition.

Wouldn't checking out corresponding tags from Git and SVN and then
running diff on the directories (ignoring .git/ and .svn/) be
sufficient?

I think the only case where this might not be equivalent is if we
run svn in our build scripts, which I don't think we do (but if
we do do that, I don't think it's worth spending time upfront
fixing that -- I find it unlikely we will ever need to do anything
like this).

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

Re: Git migration

[Boris Kolpackov]

Cantor, Scott  writes:

> On 12/16/19, 5:08 AM, "Boris Kolpackov"  wrote:
> 
> > Please let me know if you see any issues. And if everything looks
> > good, I would like to proceed with pushing this to its "official"
> > place and then requesting that the SVN repository be made read-only.
> 
> Obviously I just had to commit the advisory and web site update; can
> we set a clear freeze date for a final conversion so I don't get in
> your way?

It's not difficult for me to pull in new changes (I've updated the Git
repo with your commit) so I don't think we need this yet. But once we
are ready to switch, we can do a freeze.

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

Git migration

[Boris Kolpackov]

I've finally got around to converting the Xerces-C++ SVN repository
to Git and the result is available for inspection here:

https://github.com/boris-kolpackov/xerces-c

The conversion log (specifically, the git-svn fetch log) is available
here:

https://codesynthesis.com/~boris/tmp/xerces-svn-git-fetch-log.txt.gz

Overall, there are no errors while all the warnings (grep for 'W:')
appear to be harmless. I can also provide the detailed conversion
procedure and commands if anyone is interested.

Please let me know if you see any issues. And if everything looks
good, I would like to proceed with pushing this to its "official"
place and then requesting that the SVN repository be made read-only.

I will convert the admin branch (into a separate Git repository, as
agreed) after that.

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

No Xerces-C++ packages in RHEL/CentOS 8

[Boris Kolpackov]

I see[1] that Xerces-C++ packages are no longer part of RHEL/CentOS 8.

Anyone knows the back story and if there are any alternative sources,
like Fedora's EPEL (web search didn't yield anything promising)?

Actually, scratch that, there is EPEL 8[2] and Xerces-C++ 3.2.2
is there[3].

[1] 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/considerations_in_adopting_rhel_8/index#removed-packages_changes-to-packages
[2] https://fedoraproject.org/wiki/EPEL
[3] https://download.fedoraproject.org/pub/epel/8/Everything/x86_64/Packages/x/

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

Re: Migration to Git

[Boris Kolpackov]

Ok, I've got the ball rolling on this, sorry for the delay:

https://issues.apache.org/jira/browse/INFRA-18755

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

Re: Migration to Git

[Boris Kolpackov]

Cantor, Scott  writes:

> On 5/13/19, 9:23 AM, "Boris Kolpackov"  wrote:
> 
> > I also think we can drop any mentinoning of 2-series during this
> > conversion. There are, however, other bits of the documentation
> > (like Doxygen-generated). Here is step #15 that I mentioned:
> 
> That's not in the current readme [...].

I think I now understand what's going on: the xerces/c/web/ repository
is no longer used at all. Instead, it's all (including the generated
Doxygen documentation) in xerces/site/trunk/production/xerces-c/.

I think it then makes sense to omit web from conversion to Git.

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

Re: Migration to Git

[Boris Kolpackov]

Roger Leigh  writes:

> Mentioned briefly a few months back, but we could take the Git migration as
> an opportunity to convert the old StyleBook XML to Markdown and move the
> docs to github pages, generated directly from git automatically.

I assume the "github pages" part is acceptable to Apache due to the
recent announcement?


> I would certainly be happy to do the conversion, if there was consensus for
> doing so.

Yes, please. I doubt anyone will object but I think we will need a
vote to be compliant with the Apache way.

I also think we can drop any mentinoning of 2-series during this
conversion. There are, however, other bits of the documentation
(like Doxygen-generated). Here is step #15 that I mentioned:

15. Update the website by taking a binary package and extracting the 
doc/html directories. The web pages are stored in 
/www/xml.apache.org/xerces-c. You will also need to update the
documentation pdf in the pdf directory (which has both a pdf and
pdf.tar.gz). Recommend copying the new documentation over the
existing files. Be sure to change the permissions on the files
and directories:

find . -type f -exec chmod 664 {} ;
find . -type d -exec chmod 775 {} ;

If the binaries are for different platforms you may also need to 
update the download.html file to point to the new binaries.
Verify that the website is updated (may take a while to be 
refreshed on the real webserver).


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

Re: Migration to Git

[Boris Kolpackov]

Cantor, Scott  writes:

> On 4/29/19, 10:34 AM, "Boris Kolpackov"  wrote:
> 
> > The latter two are direct copies from the web/ and admin/ SVN directories.
> 
> I believe that the web/ repository is actually directly published as
> the web site, so there probably is additional work to do to change
> how that's happening. I don't know the details of how it works, that
> step to commit to svn was as far as I ever made it.

Hm, looking at admin/release-procedure.txt, step 15 in particular,
suggest that it's at least not the whole process.

In any case, I suggest that we convert it to Git now and decide
what extra steps, if any, are required later.


> > I think we should try to migrate the release tags (the ones
> > in the Xerces-C_X_Y_Z form). I also wouldn't mind converting
> > them to the now well-established vX.Y.Z form.
> 
> I would cast a mild vote of preference for just using X.Y.Z for
> the tag names rather than embellishing them at all with any other
> characters, but otherwise +1

I have two reasons to prefer vX.Y.Z over just X.Y.Z:

1. This is the convention that is promoted (and sometimes
   required, like in Go) in modern languages and package
   manager. As a result, it is well recognized by tooling
   (e.g., GitHub will automatically recognize a tag like
   this as a release).

2. We may want to use X, X.Y, or X.Y.Z for release-series
   branches. We currently call such branches as xerces-X.Y
   but if you think about it, this 'xerces-' prefix is
   tautological (we are already in the xerces-c repository).

So, to summarize, vX.Y.Z has potential benefits without any
drawbacks that I can think of. So why not?

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

Re: Migration to Git

[Boris Kolpackov]

Roger Leigh  writes:

> > xerces-cxx.git
> > xerces-cxx-web.git
> > xerces-cxx-admin.git
> 
> Do we need "-cxx" as a suffix here, or would "-c" be better?

Yes, good point. Our source distributions are called xerces-c, binary
packages seem to also be called like that (e.g., Debian's, libxerces-c).
So, yes, let's make it xerces-c.git, etc.

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

Migration to Git

[Boris Kolpackov]

The vote to migrate the Xerces-C++ repository from SVN to Git has
passed and I would like to discuss the next step.

According to https://gitbox.apache.org, this should be as easy
as opening and issue with the Apache Infra. Before doing this,
however, it would be good to agree on the desired repositories
and their structure.

I've browsed through some of the existing project on Gitbox
looking for established practices:

https://gitbox.apache.org/repos/asf

As well as through the Xerces-C++ SVN repository to see what
we've got:

http://svn.apache.org/viewvc/xerces/c/?root=Apache-SVN

Based on that I would suggest that we have the following
repositories:

xerces-cxx.git
xerces-cxx-web.git
xerces-cxx-admin.git

The latter two are direct copies from the web/ and admin/ SVN
directories.

For the first repository I propose the following straightforward
mapping:

heads/master  <-  trunk
heads/xerces-2<-  branches/xerces-2
heads/xerces-2.8  <-  branches/xerces-2.8
heads/xerces-3.0  <-  branches/xerces-3.0
heads/xerces-3.1  <-  branches/xerces-3.1

I think we should try to migrate the release tags (the ones
in the Xerces-C_X_Y_Z form). I also wouldn't mind converting
them to the now well-established vX.Y.Z form.

Roger and everyone else, does this sound reasonable/doable?

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

Re: Call for vote on migrating Xerces-C++ repositories to Git

[Boris Kolpackov]

Boris Kolpackov  writes:

> I would like to call for a vote to migrate Xerces-C++ SVN repositories
> to Git, specifically, to the Apache Gitbox service:
> 
> https://gitbox.apache.org/

The vote passes with 7 in favor and 0 against.

Shortly I am going to send an email to c-dev with the proposed
next steps.

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

Call for vote on migrating Xerces-C++ repositories to Git

[Boris Kolpackov]

I would like to call for a vote to migrate Xerces-C++ SVN repositories
to Git, specifically, to the Apache Gitbox service:

https://gitbox.apache.org/

This is my +1.

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

Re: Git source repository

[Boris Kolpackov]

Roger Leigh  writes:

> With the reboot of the Xalan PMC, the Xalan SVN repositories are currently
> being converted to Gitbox.

For those unaware, Gitbox is the Apache's Git service with writable
mirroring on GitHub:

https://gitbox.apache.org/


> Would it please be possible to do this for the Xerces repositories as well?
> I would be happy to assist with it.

Yes, that would be nice (and sorry for letting this slide after
bringing it up a few weeks ago).

I think before we can pull the trigger, we should have a formal
vote (even though there were no objections during the last
discussion).

Do you want to start it or I can do it?

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

Re: Support for build2, migration to git, etc

[Boris Kolpackov]

Cantor, Scott  writes:

> Practically speaking, the security process and the web site have been the
> main sources of friction for me, and I think the latter is definitely a
> choice. We could simply accept that it's not viable and shut it down in
> favor of a simple wiki page with the download links, etc.

Agree.


> Apache's security process is definitely a source of problems for me, it
> demands too much effort and is one of the reasons I tend to look for reasons
> not to do them. I don't believe in doing the work of downstream packagers as
> a precondition for doing fixes, and their process leans too far in that
> direction.

Ok, didn't know that.


> I just believe in transparency so everybody knows the situation.

Yes, I agree we should make it clear if/when things are insecure.
And I think it is also perfectly reasonable to switch to "disabled
by default" for functionality (such as DTD) which has known security
issues but which we cannot fix (for whatever reasons).


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

Re: Support for build2, migration to git, etc

[Boris Kolpackov]

Roger Leigh  writes:

> I'm doing all my work in git using the git mirror anyway,, so I would be
> more than happy to use git for the main repository.  It's much more
> efficient.

Great!


> Regarding build2, are there sufficient benefits over the existing autotools
> and cmake build to make it worth the cost for supporting three build
> systems?

Continuous CI would be the major benefit. And I am committing to absorbing
the costs by maintaining it (also see below).


> Maintaining two with exact feature parity and behaviours is already a
> maintenance burden.  I think three is too many, and would recommend we
> drop one if we are going to support a new one.  And I think that would
> have to be the autotools build.

I would prefer not to make support for build2 conditional on dropping
support for autotools (but we can vote on this separately if you would
like). As I mentioned above, we are prepared to do all the maintenance.
In fact, bared some major restructuring, I don't expect there to be any.
In particular, addition/removal/renaming of source code will be picked
up automatically. Upon release, the version will need to be changed in
one place but I am prepared to handle that as well.


> Regarding the CI side, can it integrate with Apache's github repo like we
> have already for Travis and AppVeyor?

build2 CI is a bit different in that it is "push" rather than "pull".
That is, you normally develop something in a branch, then CI it, if
all looks good, merge to master and then maybe CI master, for good
measure.

This is not to say that we can't also trigger it from a post-commit
hook or some such.


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

Re: Support for build2, migration to git, etc

[Boris Kolpackov]

Cantor, Scott  writes:

> No concerns with git, if that's something Apache allows as the
> "official" repo now [...]

I would sure hope so.


> My only concern with the build system is that I need the autoconf
> support so as long as that's not going anywhere, anything else is
> up to the people offering to maintain it.

Yes, it will be purely additive and I am committing to maintaining
it.


> FWIW, GitHub's terms of use are impossible for me to accept for
> any active development work due to their indemnification clause.

I used GitHub as an example. I am happy with any similar service
(e.g., GitLab).


> If I were to fork, it would only be in the interest of ensuring that
> nobody else used the code under the impression it were being maintained
> for general use, and to ensure that the library naming wouldn't conflict
> with any other packaging.

Well, my motivation for forking would be to continue maintaining the
project for general use but with less "friction".

I also think you are over-burdening yourself with responsibility:
yes, security issues are bad news but in the end the license clearly
states that things come as-is and without any warranty.


> But fundamentally, the issue is viability.

We have a product (CodeSynthesis XSD) that depends on it so we are
planning to use and maintain it going forward. At the same time we
view it as a mature (if not legacy) codebase so we have no plans to
add any new features, etc. I am, however, not sure whether Apache is
interested in a project like this.

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

Support for build2, migration to git, etc

[Boris Kolpackov]

I would like to add support for the build2[1] build system, similar
to how it was done recently for CMake. One of the benefits will be
continuous building and testing[2] on a wide range of platforms and
compilers[3] (currently 33). I am committing to maintaining this
support going forward.

Before doing this (and provided there is support in the first place,
of course), I would really like to migrate the project from svn to
git (hopefully with the help of Apache Infra). Last time this came
up, I don't believe there were any strong opposition to such a
switch.

I would like to put these two points to a vote but before doing so
I thought I would check what the sentiment is.

Finally, seeing that we are on the topic of migration and switching,
the question of the overall viability as the Apache project has come
up recently and some mentioned that they have considered forking the
project and hosting the fork in a less "structured" setting (e.g.,
GitHub). So maybe it makes sense to consider/discuss this possibility
as well (perhaps it could be a "move" rather than a fork if Apache is
no longer interested in the project).

What do you think?

[1] https://build2.org/
[2] https://ci.cppget.org/
[3] https://ci.cppget.org/?build-configs

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

Re: Xerces-C 3.2.1 - call for vote

[Boris Kolpackov]

+1 & thanks for all the hard work!

Boris

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

Re: Can we assume C99?

[Boris Kolpackov]

Cantor, Scott  writes:

> I don't know what the baseline has been for the code base, is C99 a
> reasonable requirement?
> 
> I need SIZE_MAX to fix some bounds checking errors, just need to know
> if I need to waste time on an autoconf test for it.

My experience has been that supporting a standard (like C99 or C++98)
is pretty pointless, especially for things like C++11 and beyond: most
compilers these days only support a subset of their features. Your case
is a good example: VC is not C99-compliant but has SIZE_MAX. When it
comes to C++, VC supports features from 14 and 17 while not being fully
C++11-compliant.

So what we found works much better is to define a set of compilers and
their versions that we support -- any feature supported by all of them
is fair play.

Perhaps we should do something like this for Xerces-C++, especially if
we plan to start migrating to C++11. In fact, this will be a great aid
to gradual migration since we can just start using new features if they
are available in all the supported compilers.

Boris

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

Re: Integrating CMake support for xerces

[Boris Kolpackov]

Roger Leigh  writes:

> If we every wanted to drop the Autotools to only have one system to
> maintain, this would provide compatibility with a traditional
> configure/make/make install workflow.  I'm not suggesting doing this at this
> point in time, just wanted to mention the existence of this solution as a
> possibility for the future.

It would still require CMake to be installed, right? One of the main
advantages of autotools is all you need is a compiler (and make),
everything else is included.

I think if we drop autotools, then we drop them good, without hitching
ourselves to some half-solutions with questionable long-term prospects.

Boris

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

Re: Status of trunk / main-3.3 comparison

[Boris Kolpackov]

Hi Scott,

Cantor, Scott  writes:

> If anybody who knows the DOM impl could weigh in on what the heck that
> code in DOMCasts.hpp/cpp was doing and why, I'd welcome the perspective.

Yeah, infamous Xerces-C++ brain-death ;-)

Try to replace this (and if it works other similar) function with:

template 
static inline DOMNodeImpl*
castToNodeImpl(const T* p)
{   
  return >fNode;
}

There might still be some cases you you will have to cast the argument
to appropriate DOM*Impl type.

Boris

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

Re: Call for vote

[Boris Kolpackov]

+1, Thanks Scott! Unfortunately couldn't find time to test.

Boris

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

Re: Status of cleanup after release

[Boris Kolpackov]

Hi Scott,

Cantor, Scott canto...@osu.edu writes:

 I have one last TODO, which is to rewrite the admin/release-procedure
 file to reflect the actual process [...]

Yes, that would definitely be very helpful. I haven't done it myself
when I did the release which I regretted many, many times.

Thanks again for you work!

Boris

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

Re: [VOTE] release of 3.1.2

[Boris Kolpackov]

+1

Thanks, Scott!

Boris

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

Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

[Boris Kolpackov]

Hi Scott,

Cantor, Scott canto...@osu.edu writes:

 I don't either, but to be blunt, the branch shouldn't be in the state it's 
 in if you think it needs that much testing, because if a security issue 
 pops up, you don't have the luxury of taking a lot of time.
 
 I completely understand your point about using the trunk, and I agree with 
 it. It's not worth the risk. But any fixes to the branch should be very 
 carefully looked at, in which case testing can be fairly pro-forma.

It is no so much the changes that I am worried about. It is the fact
that a lot of outside things (platforms, compilers, libraries, etc)
that Xerces-C++ depends on have changed a lot.

But, also, knowing what kind of a rotten mess Xerces-C++ code base
is, it is hard to know what even a trivial change will trip up.


 I am not going to add in project files for a compiler I can't test. That 
 flies in the face of the exact point you made above. If you think the 
 files on trunk work, we can add them.

Add them and I will test.


 As far as docs go, I obviously need specifics.

You will have to go through the website docs and figure what needs
updating. If something specific is unclear, ask and I will try to
help. But don't expect me to provide a step-by-step guide for you.
I unfortunately really don't have the time for that right now.


 Do you think I do have time?

I am not asking you to do anything.


 After about 2011-2012 or so, the branch simply died. Every fix was applied 
 to trunk only, even when it was minor.

Ok, I guess I missed that.

Boris

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

Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

[Boris Kolpackov]

Hi Scott,

Cantor, Scott canto...@osu.edu writes:

 It's been years, Boris. I think you're being very aggressive here with 
 somebody trying to help and able to do so only within the limits of his 
 own funding and project needs. That's how this stuff works. If you're 
 going to set requirements that I can't meet, then there's not much I can 
 say.

See it from my POV: I have a ton of users that are pretty happy with
3.1.1. Now comes Scott and wants to cut a half-tested release just
to satisfy his immediate needs. Once you do this I will start getting
emails from my users saying why doesn't my stuff (which depends on
Xerces-C++) works in this or that situation. I don't want that.



 I can't go back and review every commit you all have made. I can be very 
 careful with any commits *I* make, and I can test my use cases and allow a 
 bit of time beyond that. If you're asking me to wait months, no, I can't 
 do that. I have constraints too.

Nobody is talking about months. Here is what I suggest you do:

1. Prepare the release (with all the updates to docs, new projects,
   etc).
   
2. Publish it as a pre-release for, say, a week (i.e., announce on
   the lists).
   
3. I will test it to the best of my abilities (even though I have
   absolutely zero time for it right now) and report any problems
   (I will also review the changes for any ABI breakage).
   
4. If all looks good, you publish the release.

BTW, I am surprised you had to back-port so many bug fixes to the
3.1 branch. Normally anything that is backwards-compatible gets
committed to both head and 3.1. Are you sure you are using 3.1
and not, say, 3.1.1?

Boris

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

Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

[Boris Kolpackov]

Hi Scott,

Cantor, Scott canto...@osu.edu writes:

 Correction, it's not an ABI change, the pool entry class isn't exported on 
 Windows...

What about other platforms?! If this class is defined in a public header
(i.e., a header that is installed) and the function is virtual, then this
is an ABI change.

Boris

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

Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

[Boris Kolpackov]

Hi Scott,

Cantor, Scott canto...@osu.edu writes:

 I definitely don't have the cycles for a beta and it wouldn't fit my 
 timeline anway.

Then you shouldn't be making the release.


 I'm on VC10 for my builds, and I believe those are already there.

What about other users of Xerces-C++? When we publish a new release,
it is presumed that it will work on all commonly-used platforms and
compilers, not only what Scott Cantor needs.


 What's the bare minimum we can do once I have a tarball tested?

Bare minimum is to make sure 3.1.2 is as good quality as 3.1.1. I
don't think you are approaching it with the right attitude. If all
you need is a bug-fix that only has to work for your specific case,
then just provide a patch (or a patched version of Xerces-C++) to
your users.

Boris

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

Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

[Boris Kolpackov]

Hi Scott,

Cantor, Scott canto...@osu.edu writes:

 I've reviewed all the resolved issues against the trunk, and backported 
 15-20 or so to the branch.
 
 Once I have access I'll commit.

Before you do this have someone review your back-ports to double
check there are no ABI breakages.

Boris

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

Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

[Boris Kolpackov]

Hi Scott,

Cantor, Scott canto...@osu.edu writes:

 FWIW, I've done very little testing of trunk other than building it,
 so I don't have a sense of how good a shape it's in or how much has
 changed.

Unless you are prepared to do a good amount of testing (I can help
somewhat but you will have to take the lead, e.g., package a beta,
announce it, etc, etc), I would strongly suggest that you do the
bug-fix release (i.e., 3.1.2). Simply back-port the fix that is
only on trunk (and maybe check if there are more fixes that haven't
been applied to the 3.1). Stillm packaging a beta is probably a
good idea. As is adding new VC++ project/solution files (i have
them in XSD but they use different DLL naming).

Also, I must warn you, Xerces-C++ release process is probably
the most brain-dead thing you will ever experience. There is
the admin/ repository with some outdated release information.
I will also try to answer questions if you have any (I've done
the last couple of releases).

Boris

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

[ANN] CodeSynthesis XSD 4.0.0 released, adds support for C++11

[Boris Kolpackov]

Hi,

I am pleased to announce the release of CodeSynthesis XSD 4.0.0.

XSD is an open source, cross-platform W3C XML Schema to C++ data
binding compiler. Provided with a schema, it generates C++ classes
that represent the given vocabulary as well as XML parsing and
serialization code. You can then access the data stored in XML
using types and functions that semantically correspond to your
application domain rather than dealing with elements, attributes,
and text in a direct representation of XML such as DOM or SAX.

Major new features in this release:

  * Support for C++11 in addition to C++98.

  * Support for ordered types including mixed content.

  * Support for anyType and anySimpleType content extraction as
DOM and text, respectively.

  * Improved streaming, partially in-memory parsing and serialization
support including better XML namespace handling and streaming at
multiple document levels.

  * Automatic generation of make-style dependency information.

This release also adds support for Clang as well as Visual Studio 2012
(11.0) and 2013 (12.0).

A more detailed discussion of these features can be found in the following
blog post:

http://www.codesynthesis.com/~boris/blog/2014/07/22/codesynthesis-xsd-4-0-0-released/

For the complete list of new features in this version see the official
release announcement:

http://www.codesynthesis.com/pipermail/xsd-announcements/2014/41.html

XSD is written in portable C++ (both C++98/03 and C++11 are supported) and
you should be able to use it with any reasonably modern C++ compiler. In
particular, we have tested this release on GNU/Linux (x86/x86-64), Windows
(x86/x86-64), Mac OS X (x86), and Solaris (x86/x86-64/SPARC) with GNU g++
4.2.x-4.8.x, MS Visual C++ 2005, 2008, 2010, 2012, 2013, Sun Studio 12u2,
and Clang 3.x.

More information, documentation, source code, and pre-compiled binaries
are available from:

http://www.codesynthesis.com/products/xsd/

Enjoy,
Boris


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

Re: Issue with collapsing whitespace in a union during schema validation

[Boris Kolpackov]

Hi,

Rob Cameron r...@international-characters.com writes:

 This is a very clear and useful test case demonstrating the issue.
 I think you are correct.  Your sample file should validate against either
 schema. I am ccing the c-dev@xerces list because it appears to be a bug
 in Xerces itself.

I would suggest that you also file a bug report in Jira (and attach
the test case) so that this doesn't get lost. We can then try to fix
it for the next release.

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Compiler-based ORM system for C++  http://codesynthesis.com/products/odb
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde

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

Re: Regarding Xercesc++ performance

[Boris Kolpackov]

Hi Rinil,

Baxi, Rinil Rushabh rinil.b...@hp.com writes:

 I have 2 Xerces-C++ libraries available on my platform (2.4 and 3.1).
 Both are built without threads. I am trying to compare performance
 of both of them. To compare performance I am using different sized
 xml files to parse using the samples (1kb, 65kb, 256Kb, 1Mb, 2Mb,
 5Mb and 15Mb). I have put each sample in a script and run the same
 sample 1000 times to compare the parsing time.

Hm, I wouldn't do it like that. I would make the test itself perform
1000 iterations and also include a few warm up iterations. If you are
interested, CodeSynthesis XSD[1], which is based on Xerces-C++, includes
'performance' examples that show how to do this. They also show how
to configure Xerces-C++ parsers for optimal performance (things like
schema preloading, etc). The one for DOM is in examples/cxx/tree/ and
the one for SAX2 -- examples/cxx/parser/.

 
 We observed that till 1Mb xml file size performance of Xerces-C++ 3.1
 is better after that it starts deteriorating.

We definitely tested the performance difference between 2 and 3-series
and I am pretty sure Xerces-C++ 3 did consistently better.

[1] http://www.codesynthesis.com/products/xsd

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Compiler-based ORM system for C++  http://codesynthesis.com/products/odb
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde

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

Re: Xerces-C / Patch Release Request

[Boris Kolpackov]

Hi Scott,

Cantor, Scott canto...@osu.edu writes:

 I'm happy to spend some time testing the build on my supported platforms
 once it's ready to go.

Yes, that would great. The more testing we can get done, the better.


 I would suggest as a way of perhaps reducing time commitment than actually
 producing binaries for other than Windows is not a great use of time.

Yes, I was also thinking along those lines, especially for platforms
like HPUX, AIX, etc. But perhaps you are right, maybe we should drop
everything except Windows. Would be good idea to send an email to the
lists and check if anyone objects.

Boris

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

Re: Xerces-C / Patch Release Request

[Boris Kolpackov]

Hi Steven,

shath...@e-z.net shath...@e-z.net writes:

 I would like to see a patch release for Xerces-C (XML Parser).
 
 The current version of Xerces is 3.1.1.
 I propose a patch relase of Xerces-C as 3.1.2.

A bugfix release (e.g., 3.1.2) would normally be released to fix
something, not to add new features. So I think we should aim for
3.2.0 (from trunk).


 Tasks:
 *  Update the version.incl file
 *  Merge the trunk to the 3.1 branch
 *  Perform quality assurance testing on the 3.1 branch
 *  Update the Xerces-C website documents
 *  Package the distributions
 *  Submit the distribution artifacts to the mirrors
 *  Announce a patch release

I wish it were that easy ;-). A (possibly incomplete) list of release
tasks can be found here:

http://svn.apache.org/viewvc/xerces/c/admin/release-procedure.txt?view=log

The major ones are:

- Test on all the platforms/C++ compilers that we claim to support
- Build binaries for all the platforms/C++ compilers that we claim to support
- Update (brain-dead) Xerces-C++ website management system

I also remember last time I did a release, Apache infra people told
me that it was the last time we were able to publish our binaries
(I think it were the binaries) that way and we would have to change
to the new way with the next release. Not sure what that would
involve.

Overall, Xerces-C++ release is quite a tedious and often frustrating
process, not something you would want to do often (which is also the
reason why you would try to get it right the first time).


 I can offer some assistance at getting the Xerces-C patch release
 ready for distribution.

I was hoping to find time and make a release around June or July.
It would also be a good idea to spend some time and try to fix some
new bugs that have been uncovered since the 3.1.0 release. Not sure
if you would like to wait or if you want to press ahead. But your
help would be greatly appreciated.

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Compiler-based ORM system for C++  http://codesynthesis.com/products/odb
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde

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

Re: [VOTE]: Set up admin group for Xerces Wiki to eliminate SPAM

[Boris Kolpackov]

Sounds good to me. +1.

Boris

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

Re: Xerces_C - Microsoft Upgrade

[Boris Kolpackov]

Hi,

shath...@e-z.net shath...@e-z.net writes:

 FYI: Windows - Cygwin and MinGW
 
 These systems are deprecated.

I don't think anyone deprecated MinGW. Everything should build
fine with autotools and I see at least MinGW supported in the
future.

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Compiler-based ORM system for C++  http://codesynthesis.com/products/odb
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde

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

Re: Xerces Performance Acceleration Project: icXML

[Boris Kolpackov]

Hi Rob,

Rob Cameron r...@international-characters.com writes:

 icXML is the name of our project to dramatically accelerate
 Xerces performance on modern commodity processors by taking
 advantage of SIMD and multicore capabilities and parallel bit
 stream technology.

I wanted to try icXML with CodeSynthesis XSD[1] for some time
now. Just haven't been able to find the time.

I have a few questions:

1. It is my understanding that icXML is interface-compatible
   with Xerces-C++ 3-series. Is that correct?

2. Have you done any parallelization of the XML Schema validation
   engine?

3. You've shown results for icXML in two configurations, single-
   threaded and with 2 threads. Is there any documentation that
   describes these extra parameters/options/etc. In other words,
   how would I go about specifying the number of threads?

[1] http://www.codesynthesis.com/products/xsd/

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Compiler-based ORM system for C++  http://codesynthesis.com/products/odb
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde

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

Re: Xerces-C version identifiers in svn trunk

[Boris Kolpackov]

shath...@e-z.net shath...@e-z.net writes:

 The current xerces-c released version is 3.1.1 -- the development
 svn.a.o/xerces/c/trunk still references 3.1.0 in the following files.

The trunk will eventually become 3.2.0.

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Compiler-based ORM system for C++  http://codesynthesis.com/products/odb
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde

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

[jira] [Commented] (XERCESC-1971) Cannot build on Mac OS X 10.7

[Boris Kolpackov (JIRA)]

[ 
https://issues.apache.org/jira/browse/XERCESC-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13084825#comment-13084825
 ] 

Boris Kolpackov commented on XERCESC-1971:
--

Nathaniel, Xerces-C++ 2.8.0 is no longer maintained/supported. There will be no 
new releases in 2-series. Have you tried to build Xerces-C++ 3.1.1?

 Cannot build on Mac OS X 10.7
 -

 Key: XERCESC-1971
 URL: https://issues.apache.org/jira/browse/XERCESC-1971
 Project: Xerces-C++
  Issue Type: Bug
  Components: Build
Affects Versions: 2.8.0
 Environment: Mac OSX 10.7 (Lion).   Must be built in 64-bit mode to 
 be binary-compatible with standard Lion builds.
Reporter: Nathaniel Tagg

 This has been seen before, for example:
 http://web.archiveorange.com/archive/v/3yUylsC2yFLq8CqyP0Ml
 The code will not build, failing in several places. I do not require Mac OSX 
 specific tools; I'd be very happy with just POSIX-compliant libraries, if 
 such a build option were possible.
 Although one can download a 32-bit binary, it will not compile against 
 standard 64-bit binaries in other code. I'm compiling  a large number of 
 other libraries against XercesC, and cannot modify the build systems to build 
 on 32-bit mode.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Commented: (XERCESC-1959) serializeGrammars does not work between 32 and 64 bit systems

[Boris Kolpackov (JIRA)]

[ 
https://issues.apache.org/jira/browse/XERCESC-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13002969#comment-13002969
 ] 

Boris Kolpackov commented on XERCESC-1959:
--

Daniel, I agree the current implementation is not ideal so if you would like to 
come up with a patch, then that would be very welcome.

David, regarding backwards compatibility, there is a format version number 
stored with the binary representation. Now, the problem is that the version 
itself is stored in a non-portable manner. Luckily it is always 32-bit 
(unsigned int) so we can write 0x there for the new format which will 
make sure that any previous version (regardless of the endianness) will not 
compare equal.


 serializeGrammars does not work between 32 and 64 bit systems
 -

 Key: XERCESC-1959
 URL: https://issues.apache.org/jira/browse/XERCESC-1959
 Project: Xerces-C++
  Issue Type: Bug
  Components: Validating Parser (XML Schema)
Affects Versions: 3.1.1
 Environment: Win Vista 32 bit + VS 2010 express, Xerces-C 3.1.1 binary
 Ubuntu 10.10 64 bit, Xerces-C 3.1 installed
Reporter: Daniel Turcanu

 Serialization of schema grammar does not work between Windows 32 and Linux 64 
 bit. Serializing on one machine (with serializeGrammars) and deserializing on 
 the other (with deserializeGrammars) fails ungracefully.
 Serializing and deserializing on the same machine works fine.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: Win32TransService.obj LNK2019 error

[Boris Kolpackov]

Hi Mayra,

Please post usage questions to the c-us...@xerces.apache.org mailing list
instead of c-dev.

Mayra mlchav...@gmail.com writes:

 1XercesLib.lib(Win32TransService.obj) : error LNK2019: unresolved external
 symbol __imp__RegQueryValueExA@24 referenced in function bool __cdecl
 xercesc_3_1::isAlias(struct HKEY__ * const,char * const,unsigned int)
 (?isAlias@xercesc_3_1@@YA_NQAUHKEY__@@QADI@Z)

You are linking to a static version of Xerces-C++ library. All the unresolved
symbols are Registry functions. You need to link your application to
Advapi32.lib.

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Compiler-based ORM system for C++  http://codesynthesis.com/products/odb
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde

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

Re: Error configuring Xerces 3.1.1

[Boris Kolpackov]

Hi Helen,

Helen Gao h...@tibco.com writes:

 When I run ./configure, I got some errors in config.log.  

 conftest.c:11:28: ac_nonexistent.h: No such file or directory
 
 conftest.cpp:81:39: CoreServices/CoreServices.h: No such file or
 directory

This is normal as configure performs various tests and some of them
are expected to fail on some platforms. If you see no errors in
STDERR and the script existed with 0, then everything went fine.

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Compiler-based ORM system for C++  http://codesynthesis.com/products/odb
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde


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

Re: Static Xerces 3.0.0 lib for HPUX pa-risc architecture

[Boris Kolpackov]

Hi Gundja,

Gundja gundja.skladi...@gmail.com writes:

 I am trying to use Xerces 3.0.0 at HPUX pa-risc 32 bit box.
 I am trying to find static Xerces lib (3.0.0) version but did not have luck
 with it so far.
 
 Is it available?

PA-RISC is discontinued by both HP and Xerces-C++.

 And if there is no out of box binaries is there a way to build it for
 pa-risc 32 bit.

Follow the build instructions for UNIX and add --disable-shared to the
configure command line.

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Compiler-based ORM system for C++  http://codesynthesis.com/products/odb
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde

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

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

[Boris Kolpackov (JIRA)]

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

Boris Kolpackov updated XERCESC-1951:
-

Fix Version/s: (was: 3.1.1)

Thanks for the patch.

 Missing Libs.private in the xerces-c pkg-config file
 

 Key: XERCESC-1951
 URL: https://issues.apache.org/jira/browse/XERCESC-1951
 Project: Xerces-C++
  Issue Type: Bug
  Components: Build
Affects Versions: 3.1.1, 3.1.2, 3.2.0, 4.0.0
 Environment: MinGW cross compiling
Reporter: Volker Grabsch
 Fix For: 3.1.2, 3.2.0, 4.0.0

 Attachments: xerces-fix-pkgconfig.patch


 When compiling Xerces statically with libCURL support, the command
 pkg-config xerces-c --static --libs
 does not output the CURL lib and its dependencies. This finally leads to 
 linker errors.
 The attached patch fixed this issue.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Created: (XERCESC-1950) Build-in UCS4 transcoder does not respect endianess

[Boris Kolpackov (JIRA)]

Build-in UCS4 transcoder does not respect endianess
---

 Key: XERCESC-1950
 URL: https://issues.apache.org/jira/browse/XERCESC-1950
 Project: Xerces-C++
  Issue Type: Bug
  Components: Utilities
Affects Versions: 3.1.1
 Environment: any
Reporter: Boris Kolpackov
 Fix For: 3.1.2, 3.2.0
 Attachments: test.xml

Built-in UCS4 transcoder does not respect endianess of the requested encoding. 
Try this on the attached test file:

DOMPrint -wenc=UCS-4LE -wfile=le.xml test.xml
DOMPrint -wenc=UCS-4BE -wfile=be.xml test.xml

The resulting two files will have the same representations for long 
characters, little-endian if run on LE machine, and big-endian if run on a BE 
machine. The UTF-32 transcoder doesn't seem to have this problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (XERCESC-1950) Build-in UCS4 transcoder does not respect endianess

[Boris Kolpackov (JIRA)]

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

Boris Kolpackov updated XERCESC-1950:
-

Attachment: test.xml

 Build-in UCS4 transcoder does not respect endianess
 ---

 Key: XERCESC-1950
 URL: https://issues.apache.org/jira/browse/XERCESC-1950
 Project: Xerces-C++
  Issue Type: Bug
  Components: Utilities
Affects Versions: 3.1.1
 Environment: any
Reporter: Boris Kolpackov
 Fix For: 3.1.2, 3.2.0

 Attachments: test.xml


 Built-in UCS4 transcoder does not respect endianess of the requested 
 encoding. Try this on the attached test file:
 DOMPrint -wenc=UCS-4LE -wfile=le.xml test.xml
 DOMPrint -wenc=UCS-4BE -wfile=be.xml test.xml
 The resulting two files will have the same representations for long 
 characters, little-endian if run on LE machine, and big-endian if run on a BE 
 machine. The UTF-32 transcoder doesn't seem to have this problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (XERCESC-1947) XMLUTF8Transcoder::transcodeTo fails with an exception when transcoding single characters that require 3 or more bytes as UTF8.

[Boris Kolpackov (JIRA)]

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

Boris Kolpackov updated XERCESC-1947:
-

Fix Version/s: 3.2.0
   3.1.2

Ben, the reason I am interested in whether this affects parsing/serialization 
is because if it does then we have a critical issue and a bug-fix release is 
probably needed. If it only affects TranscodeToStr, which is only used in a few 
net accessors, then this is not critical (it is highly unlikely a URI will 
contain a three-byte UTF-8 sequence) and can wait until the normal release 
cycle. I think we both agree this only affects TranscodeToStr. Scheduling this 
bug for 3.1.2/3.2.0.



 XMLUTF8Transcoder::transcodeTo  fails with an exception when transcoding 
 single characters that require 3 or more bytes as UTF8.
 

 Key: XERCESC-1947
 URL: https://issues.apache.org/jira/browse/XERCESC-1947
 Project: Xerces-C++
  Issue Type: Bug
  Components: Utilities
Affects Versions: 3.1.0, 3.1.1
 Environment: Tested on mac os and debian linux. The failure is only 
 manifest on v3.1.x
Reporter: Ben Griffin
Priority: Critical
 Fix For: 3.1.2, 3.2.0

 Attachments: TransService.patch, transtest.cpp


 This can be demonstrated with the following 2 lines of code.
   const XMLCh uval [] = { 0x254B, 0x}; //BOX DRAWINGS HEAVY VERTICAL 
 AND HORIZONTAL (needs 3 bytes for utf-8)
   char* uc = (char*)TranscodeToStr(uval,UTF-8).adopt(); cout  uc  
 endl  flush; XMLString::release(uc); //faulty exception;
 The error is: terminate called after throwing an instance of 
 'xercesc_3_1::TranscodingException'

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (XERCESC-1947) XMLUTF8Transcoder::transcodeTo fails with an exception when transcoding single characters that require 3 or more bytes as UTF8.

[Boris Kolpackov (JIRA)]

[ 
https://issues.apache.org/jira/browse/XERCESC-1947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12920195#action_12920195
 ] 

Boris Kolpackov commented on XERCESC-1947:
--

Ben, is this only a problem in TranscodeToStr or can you also get this by 
parsing/serializing XML? It is my understanding that this only affects 
TranscodeToStr.

 XMLUTF8Transcoder::transcodeTo  fails with an exception when transcoding 
 single characters that require 3 or more bytes as UTF8.
 

 Key: XERCESC-1947
 URL: https://issues.apache.org/jira/browse/XERCESC-1947
 Project: Xerces-C++
  Issue Type: Bug
  Components: Utilities
Affects Versions: 3.1.0, 3.1.1
 Environment: Tested on mac os and debian linux. The failure is only 
 manifest on v3.1.x
Reporter: Ben Griffin
Priority: Critical
 Attachments: TransService.patch, transtest.cpp


 This can be demonstrated with the following 2 lines of code.
   const XMLCh uval [] = { 0x254B, 0x}; //BOX DRAWINGS HEAVY VERTICAL 
 AND HORIZONTAL (needs 3 bytes for utf-8)
   char* uc = (char*)TranscodeToStr(uval,UTF-8).adopt(); cout  uc  
 endl  flush; XMLString::release(uc); //faulty exception;
 The error is: terminate called after throwing an instance of 
 'xercesc_3_1::TranscodingException'

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (XERCESC-1936) ICUTransService and IconvGNUransService CAN NOT deal with huge file.

[Boris Kolpackov (JIRA)]

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

Boris Kolpackov updated XERCESC-1936:
-

Fix Version/s: 3.1.2
   3.2.0
   4.0.0

Yes, I just tried your test with ICU and I get the error. Scheduling this bug 
for the next release.

 ICUTransService and IconvGNUransService CAN NOT deal with huge file.
 

 Key: XERCESC-1936
 URL: https://issues.apache.org/jira/browse/XERCESC-1936
 Project: Xerces-C++
  Issue Type: Bug
  Components: Utilities
Affects Versions: 2.8.0, 3.1.1
 Environment: RHEL-5.5
 glibc-2.5-49.el5_5.2
 libicu-3.6-5.11.4
Reporter: kirby zhou
 Fix For: 3.1.2, 3.2.0, 4.0.0


 If a huge file passed to XMLReader, it will call TransService mulitple times, 
 and splite the file content into several fragments.
 Unfortunately, the fragment will contain incomplete multi-byte characters.
 But neither ICUTransService nor IconvGNUransService deal with it. 
 ICUTransService did not deal with U_TRUNCATED_CHAR_FOUND, and 
 IconvGNUransService did not deal with EINVAL.
 Both 2.8.0 and 3.1.1 have the same bug.
 For example, make 2 XML like that:
 ]# ( echo '?xml version=1.0 encoding=GBK ?'; echo 'data'; for 
 ((i=0;i2;++i)); do echo -n '中文汉字A'; done ; echo; echo '/data' )  
 ~/small.xml
 ]# ( echo '?xml version=1.0 encoding=GBK ?'; echo 'data'; for 
 ((i=0;i10;++i)); do echo -n '中文汉字A'; done ; echo; echo '/data' )  
 ~/big.xml
 # the small.xml and big.xml are analogical. 
 ]# samples/SAXPrint -x=gbk ~/small.xml 
 ?xml version=1.0 encoding=gbk?
 data
 中文汉字A中文汉字A
 /data
 # with icu
 ]# samples/SAXPrint -x=gbk ~/big.xml
 ?xml version=1.0 encoding=gbk?
 data
 Fatal Error at file /root/big.xml, line 3, char 16377
   Message: char 0x6C49 is not representable in 'gbk' encoding
 # with iconvgnu
 ]# samples/SAXPrint -x=gbk ~/big.xml
 ]# samples/SAXPrint -x=gbk ~/big.xml 
 ?xml version=1.0 encoding=gbk?
 data
 Fatal Error at file /root/big.xml, line 3, char 16377
   Message: invalid multi-byte sequence

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (XERCESC-1451) Valgrind reports mismatched new/delete[] usage

[Boris Kolpackov (JIRA)]

[ 
https://issues.apache.org/jira/browse/XERCESC-1451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12901970#action_12901970
 ] 

Boris Kolpackov commented on XERCESC-1451:
--

Daniel, Have you tried the latest release (3.1.1)? 2.8.0 is no longer supported 
so even if there is a bug, it won't be fixed in 2.x.y release series.

 Valgrind reports mismatched new/delete[] usage
 --

 Key: XERCESC-1451
 URL: https://issues.apache.org/jira/browse/XERCESC-1451
 Project: Xerces-C++
  Issue Type: Bug
Affects Versions: 2.5.0, 2.6.0
 Environment: Red Hat 9 (Shrike 2.4.20-6smp), Dell Precision 530
 Valgrind 2.4.0
 g++ 3.2.2
Reporter: Glenn Miyake

 Valgrind reports a mismatch new/delete[] 
 MemoryManagerImpl::allocate(unsigned) appears to allocate using just 
 new(size).
 This memory is then incorrectly freed using array delete (delete []) in 
 XMLString::release.
 Simply changing the release method to call delete does not work since it 
 appears that release is also used to free memory allocated with new [].
 Partial valgrind output follows:
 ==21267== Mismatched free() / delete / delete []
 ==21267==at 0x1B903D5D: operator delete[](void*) (vg_replace_malloc.c:161)
 ==21267==by 0x1BB0A9EC: xercesc_2_6::XMLString::release(unsigned short**) 
 (in /home/gmiyake/dev/xerces-c-src_2_6_0/lib/libxerces-c.so.26.0)
 ==21267==by 0x836BC59: 
 altova::CDoc::convertXmlDocToString(altova::CNode) (Doc.cpp:451)
 ==21267==by 0x836E059: altova::CNode::convertXmlDocToString() 
 (Node.cpp:469)
 ==21267==  Address 0x1BE20C18 is 0 bytes inside a block of size 3912 alloc'd
 ==21267==at 0x1B9036A6: operator new(unsigned) (vg_replace_malloc.c:132)
 ==21267==by 0x1BA7C51B: 
 xercesc_2_6::MemoryManagerImpl::allocate(unsigned) (in 
 /home/gmiyake/dev/xerces-c-src_2_6_0/lib/libxerces-c.so.26.0)
 ==21267==by 0x1BA49F0A: 
 xercesc_2_6::DOMWriterImpl::writeToString(xercesc_2_6::DOMNode const) (in 
 /home/gmiyake/dev/xerces-c-src_2_6_0/lib/libxerces-c.so.26.0)
 ==21267==by 0x836BC23: 
 altova::CDoc::convertXmlDocToString(altova::CNode) (Doc.cpp:440)
 ==21267==by 0x836E059: altova::CNode::convertXmlDocToString() 
 (Node.cpp:469)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (XERCESC-1940) Problem in prefix parsing while creating Documnet, Element, Attributes on all platforms : Issue is in poolString creation

[Boris Kolpackov (JIRA)]

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

Boris Kolpackov updated XERCESC-1940:
-

Fix Version/s: 3.1.2
   3.2.0

Thanks for the report, Anil. I am scheduling this for 3.1.2 and 3.2.0. Though 
the patch doesn't look portable (dynamic allocation of an array).

 Problem in prefix parsing while creating Documnet, Element, Attributes on all 
 platforms : Issue is in poolString creation
 -

 Key: XERCESC-1940
 URL: https://issues.apache.org/jira/browse/XERCESC-1940
 Project: Xerces-C++
  Issue Type: Bug
  Components: DOM
Affects Versions: 3.0.1, 3.1.1
 Environment: ALL Platform, ALL OS
Reporter: Anil G Pandge
Priority: Critical
 Fix For: 3.1.2, 3.2.0

 Attachments: DOMDocumentImpl.hpp.patch, MainPro.cpp


 Description:
 
 When I create a DOM document using xerces APIs, for very specific input its 
 creating wrong payload. This is observable on 64-bit but on 32-bit. For 
 testing I have written sample with createDocument API which creates DOM 
 document and print it in string format.
 I ran the test on following inputs:
 createDocument(types:statusSet,http://xyz.com;);
 createDocument function just create dom document and prints payloads. 
 Following is the outputs of above string on 32-bit machine.
 32 bit platforms output:
 prefix = types:statusSet
 LocalName = statusSet
 doc = types:statusSet xmlns:types:statusSet=http://xyz.com/
 ===
 Severity : Critical
 ===
 Platforms: ALL
 ==
 Cause and resolution
 
 I debugged xerces code, issue is in 
  File : DOMDocumentImpl.hpp
  Function : DOMDocumentImpl::getPooledNString(const XMLCh *in, XMLSize_t n)
 Patch:
 ==
 --- DOMDocumentImpl.hpp2008-07-24 15:58:29.0 +0530
 +++ 
 /data/eclipse_workspace/CppIT-3.1.0/XercesTEst/src/xercesc/dom/impl/DOMDocumentImpl.hpp
 2010-08-22 10:36:18.0 +0530
 @@ -401,9 +401,11 @@
pspe = fNameTable[inHash];
while (*pspe != 0)
{
 -if (XMLString::equalsN((*pspe)-fString, in, n))
 -  return (*pspe)-fString;
 -pspe = ((*pspe)-fNext);
 +  XMLCh firstN[n];
 +  XMLString::copyNString(firstN,in,n);
 +  if (XMLString::equals((*pspe)-fString, firstN))
 +  return (*pspe)-fString;
 +  pspe = ((*pspe)-fNext);
}
 Issue:
 ==
   1. getPooledNString computes hash of prefix and searches in fNameTable.
   2. Once hash is found, code cheks pooledString and 'n' characters of 
 qualifiedString. ! WRONG !
   3. if comparision is true it returns the pooled string.
   Ex:
   In case of types:statusSet, it will compare types:statusSet 
 and first 6 characters of types:, it found comparision true. It return 
 pooled string types:statusSet as prefix ! WRONG !
 How to reporduce:
 =
   Very easy to reproduce. Run the sample program I have attached.
   
 Resolution:
 ===
   I have attached patch file with resolution.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (XERCESC-1936) ICUTransService and IconvGNUransService CAN NOT deal with huge file.

[Boris Kolpackov (JIRA)]

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

Boris Kolpackov updated XERCESC-1936:
-


Hi,

Can you attach the sample files to the bug report? The content that you have 
pasted in the description is all garbled. Also, would you be able to come up 
with a patch for this issue?

 ICUTransService and IconvGNUransService CAN NOT deal with huge file.
 

 Key: XERCESC-1936
 URL: https://issues.apache.org/jira/browse/XERCESC-1936
 Project: Xerces-C++
  Issue Type: Bug
  Components: Utilities
Affects Versions: 2.8.0, 3.1.1
 Environment: RHEL-5.5
 glibc-2.5-49.el5_5.2
 libicu-3.6-5.11.4
Reporter: kirby zhou

 If a huge file passed to XMLReader, it will call TransService mulitple times, 
 and splite the file content into several fragments.
 Unfortunately, the fragment will contain incomplete multi-byte characters.
 But neither ICUTransService nor IconvGNUransService deal with it. 
 ICUTransService did not deal with U_TRUNCATED_CHAR_FOUND, and 
 IconvGNUransService did not deal with EINVAL.
 Both 2.8.0 and 3.1.1 have the same bug.
 For example, make 2 XML like that:
 ]# ( echo '?xml version=1.0 encoding=GBK ?'; echo 'data'; for 
 ((i=0;i2;++i)); do echo -n '中文汉字A'; done ; echo; echo '/data' )  
 ~/small.xml
 ]# ( echo '?xml version=1.0 encoding=GBK ?'; echo 'data'; for 
 ((i=0;i10;++i)); do echo -n '中文汉字A'; done ; echo; echo '/data' )  
 ~/big.xml
 # the small.xml and big.xml are analogical. 
 ]# samples/SAXPrint -x=gbk ~/small.xml 
 ?xml version=1.0 encoding=gbk?
 data
 中文汉字A中文汉字A
 /data
 # with icu
 ]# samples/SAXPrint -x=gbk ~/big.xml
 ?xml version=1.0 encoding=gbk?
 data
 Fatal Error at file /root/big.xml, line 3, char 16377
   Message: char 0x6C49 is not representable in 'gbk' encoding
 # with iconvgnu
 ]# samples/SAXPrint -x=gbk ~/big.xml
 ]# samples/SAXPrint -x=gbk ~/big.xml 
 ?xml version=1.0 encoding=gbk?
 data
 Fatal Error at file /root/big.xml, line 3, char 16377
   Message: invalid multi-byte sequence

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: Validate the data contained in a DOM tree

[Boris Kolpackov]

Hi Vladimir,

Vladimir Loubenski vloub...@opentext.com writes:

 My understanding that single way to validate data (Validation against
 XML schema) in a DOM tree is to create the DOM document, write it back
 as XML and re-parse it with validation turned on. Are there plans to
 support validation direct from the DOM tree?

No, there are no plans to support this at the moment. It is also 
questionable how useful this feature will be since it is not clear
what one can do when a validation error has been detected. There
are some errors that will be hard/impossible to fix programmatically
(say, pattern validation error). For a more detailed discussion of
this topic, see the following post:

http://www.codesynthesis.com/pipermail/xsd-users/2008-January/001443.html


Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde
Command line interface to C++ compiler http://codesynthesis.com/projects/cli

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

Re: Development plans for XML Schema 1.1

[Boris Kolpackov]

Hi Khaled,

Khaled Noaman knoa...@ca.ibm.com writes:

 Xerces-J 2.10 was just release and it included experimental support for 
 XML Schema 1.1. Are there any future plans to implement XML Schema 1.1 in 
 Xerces-C?

I chatted with Alberto about this the other day. It seems before we
make any major changes to the XML Schema processor in Xerces-C++, it
would be wise to decouple the validators from XML scanners and make
them just another stage in the pipeline. The current architecture
is very hard to maintain and has a number of serious shortcomings
(e.g., the fact that certain validation errors are detected only
after the SAX events have been fired).

Also, the XML Schema 1.1 spec is not yet a recommendation. I am not 
very familiar with the W3 process, but isn't it still a moving target?

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde
Command line interface to C++ compiler http://codesynthesis.com/projects/cli

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

[jira] Created: (XERCESC-1931) Add support for Windows-style UNC URIs

[Boris Kolpackov (JIRA)]

Add support for Windows-style UNC URIs
--

 Key: XERCESC-1931
 URL: https://issues.apache.org/jira/browse/XERCESC-1931
 Project: Xerces-C++
  Issue Type: Improvement
  Components: Utilities
Affects Versions: 3.1.1
Reporter: Boris Kolpackov
 Fix For: 3.1.2, 3.2.0


There are three ways to represent Windows network share paths in URI that are 
in use today:
file://host/path
file:host/path
file:/host/path

Xerces-C++ only supports the later two. The first encoding is the Microsoft 
recommended[1] and Windows API functions construct URI this way. We should 
probably add support for the first format as well.

[1] http://blogs.msdn.com/b/ie/archive/2006/12/06/file-uris-in-windows.aspx

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Closed: (XERCESC-1930) CRLF is replaced by space

[Boris Kolpackov (JIRA)]

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

Boris Kolpackov closed XERCESC-1930.


Resolution: Invalid

  CRLF is replaced by space
 --

 Key: XERCESC-1930
 URL: https://issues.apache.org/jira/browse/XERCESC-1930
 Project: Xerces-C++
  Issue Type: Bug
Affects Versions: 2.2.0
Reporter: Harpreet

 Hi, 
 Our code creates a xml where description tag contains text in the format 
 abcdCRLFefgh where CR stands for carriage return and LF stands for line 
 feed. Now when we pass the xml to xerces, the CRLF combo is converted to 
 space which is unexpected.
 Is this issue already reported? I searched over the net and in JIRA as well 
 but could not find any such reported issues.
 Is there any workaround available for this.
 Thanks
 Harpreet

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: Question About xerces code

[Boris Kolpackov]

Hi Henry,

In the future please send questions about Xerces-C++ to one of the
project's mailing lists instead of to me directly. For technical
questions like these c-dev is appropriate (which, BTW, I've CC'ed
to my reply).


Wang, Henry (LeftHand Networks) henry.wa...@hp.com writes:

 Hi. Boris;
 My name is Henry Wang, I am with HP Corp. We have a project using 
 Xerces, and we constantly have memory leak. We use Purify trying to find 
 where the leak is. Purify always point to ContentSpecNode constructor is 
 leaking memory. I studied the xerces code and have several questions here.
 I appreciate your help in understanding this code. Thanks.
 
 1. In ContentSpecNode::ContentSpecNode() constructor,
 fElement = new (fMemoryManager) QName(*element);
 
 this does not allocate memory, just replace memory allready allocated 
 by FMemoryManager, but then the destructor of ContentSpecNode is:
 
 delete fElement;
 
 This will call Standard Library delete function.
 
 Don't we have a mis-match here, the fMemoryManager should be called to 
 de-allocate memory, right ?

QName derives from XMemory which overloads operator delete() to free 
the memory using the memory manager. See the XMemory implementation 
for details.


 2. In void TraverseSchema::validateAnnotations() {
 
 we have:
 
 ContentSpecNode* left  = new (memMgr) ContentSpecNode(appInfoElemDecl, 
 memMgr);
 ContentSpecNode* right = new (memMgr) ContentSpecNode(docElemDecl, memMgr);
 ContentSpecNode* root  = new (memMgr) 
 ContentSpecNode(ContentSpecNode::ModelGroupChoice
 , left
 , right
 , true
 , true
 , memMgr);
 
 Does the memMgr smart enough to replace different section of memory 
 for these three consective replacements?, How the delete will work?

I am not sure what you mean by these. new (memMgr) ... will allocate
the memory block using the memory manager. operator delete () from
XMemory will release it.


Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde
Command line interface to C++ compiler http://codesynthesis.com/projects/cli

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

Re: svn tag for 3_1_1 missing?

[Boris Kolpackov]

Hi Ben,

Ben Griffin b...@redsnapper.net writes:

 A svn tag for Xerces-C++ 3.1.1 appears to be missing.

Sorry, I completely forgot about this. The tag is now in place. 
Thanks for reporting this!

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde
Command line interface to C++ compiler http://codesynthesis.com/projects/cli

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

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

[Boris Kolpackov (JIRA)]

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

Boris Kolpackov updated XERCESC-1925:
-

Fix Version/s: 3.1.2
   3.2.0

Scheduling for 3.1.2, 3.2.0.

 Wrong temporary token type causes regex construction to fail
 

 Key: XERCESC-1925
 URL: https://issues.apache.org/jira/browse/XERCESC-1925
 Project: Xerces-C++
  Issue Type: Bug
  Components: Utilities
Reporter: John Keeping
 Fix For: 3.1.2, 3.2.0

 Attachments: xerces-range-token-merge.patch


 When checking for token overlap in a regular expression a temporary range 
 token is constructed and merged with another range token. This temporary 
 token has type Token::T_RANGE so the merge fails if the actual token is of 
 type Token::T_NRANGE.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

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

[Boris Kolpackov (JIRA)]

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

Boris Kolpackov updated XERCESC-1926:
-

Fix Version/s: 3.1.2
   3.2.0

Scheduling for 3.1.2, 3.2.0.

 IGXMLScanner can fail to properly set its XSModel.
 --

 Key: XERCESC-1926
 URL: https://issues.apache.org/jira/browse/XERCESC-1926
 Project: Xerces-C++
  Issue Type: Bug
  Components: Validating Parser (XML Schema)
Reporter: John Keeping
 Fix For: 3.1.2, 3.2.0

 Attachments: xerces-model-update.patch


 If an IGXMLScanner is used for a document with no schema and then reset to 
 scan a document with a schema the model is not set correctly.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Closed: (XERCESC-1922) MacOSUnicodeConverter.cpp: ISO C++ forbids comparison between pointer of type 'void *' and pointer-to-function

[Boris Kolpackov (JIRA)]

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

Boris Kolpackov closed XERCESC-1922.


Fix Version/s: 3.1.2
   3.2.0
   (was: 3.1.0)
   Resolution: Fixed

Fix is in SVN, thanks.

 MacOSUnicodeConverter.cpp: ISO C++ forbids comparison between pointer of type 
 'void *' and pointer-to-function
 --

 Key: XERCESC-1922
 URL: https://issues.apache.org/jira/browse/XERCESC-1922
 Project: Xerces-C++
  Issue Type: Improvement
  Components: Build
 Environment: Mac OS X 10.6.3, g++ 4.2.1, xerces 3.1
Reporter: isidoro ghezzi
Priority: Minor
 Fix For: 3.1.2, 3.2.0

   Original Estimate: 1h
  Remaining Estimate: 1h

 Compiling with $ g++ --version
 i686-apple-darwin10-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646) (dot 1)
 having -Wall -Wextra -Wconversion -ansi -pedantic flags the result is:
 xercesc/util/Transcoders/MacOSUnicodeConverter/MacOSUnicodeConverter.cpp: In 
 static member function 'static bool 
 xercesc_3_1::MacOSUnicodeConverter::IsMacOSUnicodeConverterSupported()':
 xercesc/util/Transcoders/MacOSUnicodeConverter/MacOSUnicodeConverter.cpp:461: 
 error: ISO C++ forbids comparison between pointer of type 'void *' and 
 pointer-to-function
 xercesc/util/Transcoders/MacOSUnicodeConverter/MacOSUnicodeConverter.cpp:462: 
 error: ISO C++ forbids comparison between pointer of type 'void *' and 
 pointer-to-function
 to avoid that, i suggest to change:
 [code]
 bool
 MacOSUnicodeConverter::IsMacOSUnicodeConverterSupported(void)
 {
 return UpgradeScriptInfoToTextEncoding != (void*)NULL
  CreateTextToUnicodeInfoByEncoding != (void*)NULL
 ;
 }
 [/code]
 to:
 [code]
 bool
 MacOSUnicodeConverter::IsMacOSUnicodeConverterSupported(void)
 {
 return (0L != UpgradeScriptInfoToTextEncoding)
  (0L != CreateTextToUnicodeInfoByEncoding)
 ;
 }
 [/code]

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Closed: (XERCESC-1923) removing extras semicolon

[Boris Kolpackov (JIRA)]

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

Boris Kolpackov closed XERCESC-1923.


Fix Version/s: 3.1.2
   3.2.0
   Resolution: Fixed

The fix is in SVN, thanks!

 removing extras semicolon
 -

 Key: XERCESC-1923
 URL: https://issues.apache.org/jira/browse/XERCESC-1923
 Project: Xerces-C++
  Issue Type: Test
  Components: Samples/Tests
Affects Versions: 3.1.0
 Environment: MacOS 10.3.6, xerces 3.1, gcc 4.2
Reporter: isidoro ghezzi
 Fix For: 3.1.2, 3.2.0

   Original Estimate: 1h
  Remaining Estimate: 1h

 Compiling with $ g++ --version 
 i686-apple-darwin10-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646) (dot 1) 
 having -Wall -Wextra -Wconversion -ansi -pedantic flags the result is: 
 $ make check
 ...
 Compiling src/DOM/DOMMemTest/DOMMemTest.cpp
 src/DOM/DOMMemTest/DOMMemTest.cpp:50: error: extra ';'
 src/DOM/DOMMemTest/DOMMemTest.cpp:1489: error: extra ';'
 Compiling src/DOM/Normalizer/Normalizer.cpp
 src/DOM/Normalizer/Normalizer.cpp:203: error: extra ';'
 Compiling src/DOM/RangeTest/RangeTest.cpp
 src/DOM/RangeTest/RangeTest.cpp:55: error: extra ';'
 src/DOM/RangeTest/RangeTest.cpp:966: error: extra ';'
 Compiling src/DOM/Traversal/Traversal.cpp
 src/DOM/Traversal/Traversal.cpp:55: error: extra ';'
 src/DOM/Traversal/Traversal.cpp:557: error: extra ';'
 Compiling src/EncodingTest/EncodingTest.cpp
 src/EncodingTest/EncodingTest.cpp:82: error: extra ';'
 src/EncodingTest/EncodingTest.cpp:96: error: extra ';'
 src/EncodingTest/EncodingTest.cpp:111: error: extra ';'
 src/EncodingTest/EncodingTest.cpp:172: error: extra ';'
 src/EncodingTest/EncodingTest.cpp:443: error: extra ';'
 solved simply removing extra ; at above lines.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: [VOTE]: Nomination of Mukul Gandhi for Xerces PMC Membership

[Boris Kolpackov]

+1

Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde
Command line interface to C++ compiler http://codesynthesis.com/projects/cli

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

[jira] Closed: (XERCESC-1924) Cannot open include file: 'inttypes.h': No such file or directory

[Boris Kolpackov (JIRA)]

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

Boris Kolpackov closed XERCESC-1924.


Resolution: Invalid

Please don't ask for help by creating bug report. Rather, post your question to 
the c-users mailing list:

http://xerces.apache.org/xerces-c/mailing-lists.html


 Cannot open include file: 'inttypes.h': No such file or directory
 -

 Key: XERCESC-1924
 URL: https://issues.apache.org/jira/browse/XERCESC-1924
 Project: Xerces-C++
  Issue Type: Bug
  Components: Build
Affects Versions: 3.1.0
 Environment: Cygwin 1.7.5 running on Vista using Visual C++ 2008 
 Express Edition
Reporter: R Manger

 I am trying to install GDML add-on to Geant4, but I get an error when 
 Xerces_autoconf_config.hpp calls for 'inttypes.hh.' Here is an excerpt of the 
 compilation process:
 Compiling G4GDMLParser.cc ...
 G4GDMLParser.cc
 c:/xerces/include\xercesc/util/Xerces_autoconf_config.hpp(88) : fatal error 
 C1083: Cannot open include file: 'inttypes.h': No such file or directory
 make[2] *** [c:/Geant4/geant4_9_3/tmp/WIN32-VC/G4gdml/G4GDMLParser.o] Error 2
 make[1]: *** [objs] Error 2
 I know that Visual Studio is set up to communicate with cygwin properly 
 because I have built many other cpp toolkits in this environment. What may be 
 the problem?
 Thanks

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[ANN] CodeSynthesis XSD 3.3.0 released

[Boris Kolpackov]

Hi,

I am pleased to announce the availability of CodeSynthesis XSD 3.3.0.

CodeSynthesis XSD is an open-source (GPL2 + proprietary license), cross-
platform W3C XML Schema to C++ data binding compiler. Provided with a
schema, it generates C++ classes that represent the given vocabulary as
well as parsing and serialization code. You can then access the data
stored in XML using types and functions that semantically correspond to
your application domain rather than dealing with elements, attributes,
and text in a direct representation of XML such as DOM or SAX.

XSD uses Xerces-C++ as the underlying XML parser which allows for greater
flexibility while processing XML. For example, the data can be pre-processed
using the DOM representation before being converted to C++ classes as well
as post-processed before being serialized back to XML. Other features
that are made possible with this architecture include the representation
of XML Schema wildcard content (xs:any and xs:anyAttribute) as DOM fragments,
optional bi-directional association between DOM nodes and C++ class instances,
as well as the execution of XPath queries with the ability to access the
result as C++ class instances.

Major new features in this release:

  * Support for uniform parsing and serialization of XML documents
with varying root elements.

  * Configurable application character encoding (UTF-8, ISO-8859-1, etc).

  * Support for stream-oriented, partially in-memory/partially event-
driven XML parsing and serialization.

  * Support for embedding the binary representation of the schema
grammar into the application.

  * Generation of the detach functions that allow moving object
model sub-trees without copying. 

  * Support for XML compression.

  * Smaller and faster generated code for polymorphic XML Schemas 
(xsi:type and substitution groups).

The release also adds support for a range of new operating system and C++
compiler versions, including:

  * AIX 6.x
  * Mac OS X 10.6
  * Windows 7,
  * Windows Server 2008

  * Visual Studio 2010 (10.0)
  * GNU g++ 4.5.0
  * Intel C++ 11
  * Sun Studio 12.1
  * IBM XL C++ 11

Visual Studio 2010 project and solution files are provided for all the
examples.
  
For the complete list of new features in this release see:

http://www.codesynthesis.com/pipermail/xsd-announcements/2010/38.html

CodeSynthesis XSD is available on IBM AIX, GNU/Linux, HP-UX, Mac OS X,
Solaris, Windows, OpenVMS, and z/OS. Supported C++ compilers include: 
GNU g++, HP aCC, IBM XL C++, Intel C++, Sun C++, and MS Visual C++.

More information, documentation, source code, and precompiled binaries
for all the supported platforms are available from:

http://www.codesynthesis.com/products/xsd/


Boris

-- 
Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog
Open-source XML data binding for C++   http://codesynthesis.com/products/xsd
XML data binding for embedded systems  http://codesynthesis.com/products/xsde
Command line interface to C++ compiler http://codesynthesis.com/projects/cli

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