[GitHub] [xerces-c] Cogitri opened a new pull request #8: cmake: use HAVE_SIZE_OF_S{, S}IZE_T to check if it's available

2020-03-06 Thread GitBox
Cogitri opened a new pull request #8: cmake: use HAVE_SIZE_OF_S{,S}IZE_T to check if it's available URL: https://github.com/apache/xerces-c/pull/8 Previously if(SIZE_OF_S{,S}IZE_T) was used, which apparently isn't reliable on some platforms/CMake versions. See XERCESC-2194

[jira] [Commented] (XERCESC-2194) Including Xerces_autoconf_config.hpp on Windows fails due to undefined ssize_t

2020-03-06 Thread Rasmus Thomsen (Jira)
[ https://issues.apache.org/jira/browse/XERCESC-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17053133#comment-17053133 ] Rasmus Thomsen commented on XERCESC-2194: - https://github.com/apache/xerces-c/pull/8 >

[jira] [Commented] (XERCESC-2194) Including Xerces_autoconf_config.hpp on Windows fails due to undefined ssize_t

2020-03-06 Thread Rasmus Thomsen (Jira)
[ https://issues.apache.org/jira/browse/XERCESC-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17053130#comment-17053130 ] Rasmus Thomsen commented on XERCESC-2194: - So I just tested this on our Windows machine and it

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

2020-03-06 Thread Sylvain Beucler (Jira)
[ https://issues.apache.org/jira/browse/XERCESC-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17053366#comment-17053366 ] Sylvain Beucler commented on XERCESC-2188: -- For the record, there is another patch attempt

Re: Branching for 3.3 work?

2020-03-06 Thread Cantor, Scott
On 3/6/20, 12:01 AM, "Boris Kolpackov" wrote: > 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? That's the intended branch, but the purpose isn't to immediately release a 3.2.3, it's to

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

2020-03-06 Thread Scott Cantor (Jira)
[ https://issues.apache.org/jira/browse/XERCESC-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17053450#comment-17053450 ] Scott Cantor commented on XERCESC-2188: --- I was not aware, thank you. I'm happy to look, but the

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

2020-03-06 Thread Scott Cantor (Jira)
[ https://issues.apache.org/jira/browse/XERCESC-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17053458#comment-17053458 ] Scott Cantor commented on XERCESC-2188: --- My impression is that your proposed fix is probably a

Re: Branching for 3.3 work?

2020-03-06 Thread 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.

Re: Branching for 3.3 work?

2020-03-06 Thread Cantor, Scott
On 3/6/20, 9:23 AM, "Boris Kolpackov" wrote: > Ok, makes sense, thanks. There's also apparently some movement on 2188 from the Debian team, they may have a fix for the open security issue, but it may require a 3.3 anyway. I may have mispoke in that issue too: is there any formal definition of

Re: Branching for 3.3 work?

2020-03-06 Thread 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

Re: Branching for 3.3 work?

2020-03-06 Thread Cantor, Scott
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

Apache CLA for small contributions

2020-03-06 Thread Roger Leigh
Hi Scott, I wanted to check with you what the policy was regarding the requirement for an Apache CLA for code contributions.  Does this apply for the case of simple and obvious one-liners and other fairly trivial fixes as opposed to more substantial work which is actually creative? Are