[GitHub] [xerces-c] rleigh-codelibre commented on pull request #2: Commit fuzzer source code.

2020-06-20 Thread GitBox


rleigh-codelibre commented on pull request #2:
URL: https://github.com/apache/xerces-c/pull/2#issuecomment-647028400


   If all the work is individual and there is no corporate ownership of any of 
it, then if you both submit the needed ICLA that should be sufficient.  Thanks.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



[GitHub] [xerces-c] rleigh-codelibre commented on a change in pull request #2: Commit fuzzer source code.

2020-06-20 Thread GitBox


rleigh-codelibre commented on a change in pull request #2:
URL: https://github.com/apache/xerces-c/pull/2#discussion_r443149185



##
File path: CMakeLists.txt
##
@@ -177,8 +177,14 @@ install(
 # Process subdirectories
 add_subdirectory(doc)
 add_subdirectory(src)
-add_subdirectory(tests)
-add_subdirectory(samples)
+if (NOT (DEFINED XERCES_BUILD_FUZZERS))

Review comment:
   I would prefer that the fuzzer keep its conditionals self-contained if 
possible.  That is, rather than disabling other unrelated features, it should 
only enable or disable the fuzzing functionality.  If you want to disable 
building of the tests and/or samples, I think they should have separate options 
to allow them to be enabled or disabled independently.
   
   You could then do `-Dtests=OFF -Dsamples-OFF -Dfuzzer=ON` to achieve the 
same effect.
   
   Also, the extra compile-time stuff using ExternalProject looks separate from 
building the fuzzer itself.  Maybe always build the fuzzer but have that 
additional stuff gated on the `fuzzer` option.  Or gate all of it.  But I would 
put that conditional stuff *inside* the fuzzer CMakeLists.txt rather than 
having any conditionals around include statements.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



[GitHub] [xerces-c] viniul edited a comment on pull request #2: Commit fuzzer source code.

2020-06-20 Thread GitBox


viniul edited a comment on pull request #2:
URL: https://github.com/apache/xerces-c/pull/2#issuecomment-646989210


   @rleigh-codelibre We have not yet submitted the Apache licensing agreement - 
this is individual work by me and @bshastry, so I think if we both submit the 
ICLA this should be sufficient, correct?
   
   The two Google copyrights came because we started those two files based on a 
Google template. The final file that will be committed was written by us though 
(in fact this was written by @bshastry, could you please confirm?) -- So I 
think we can just replace the Google copyright.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



[GitHub] [xerces-c] viniul commented on pull request #2: Commit fuzzer source code.

2020-06-20 Thread GitBox


viniul commented on pull request #2:
URL: https://github.com/apache/xerces-c/pull/2#issuecomment-646989210


   @rleigh-codelibre We have not yet submitted the Apache licensing agreement - 
this is individual work by me and @bshastry, so I think if we both submit the 
ICLA this should be sufficient, correct?



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



[GitHub] [xerces-c] viniul commented on a change in pull request #2: Commit fuzzer source code.

2020-06-20 Thread GitBox


viniul commented on a change in pull request #2:
URL: https://github.com/apache/xerces-c/pull/2#discussion_r443127661



##
File path: CMakeLists.txt
##
@@ -177,8 +177,14 @@ install(
 # Process subdirectories
 add_subdirectory(doc)
 add_subdirectory(src)
-add_subdirectory(tests)
-add_subdirectory(samples)
+if (NOT (DEFINED XERCES_BUILD_FUZZERS))

Review comment:
   Fuzzing requires some compile-time instrumentation of the xerces-library 
code and certain libraries that need to be linked against the instrumented code 
later on. Since this instrumentation is not needed for the other tests, because 
I thought this way it would be cleaner. Do you still want to me to change?





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



[GitHub] [xerces-c] viniul commented on a change in pull request #2: Commit fuzzer source code.

2020-06-20 Thread GitBox


viniul commented on a change in pull request #2:
URL: https://github.com/apache/xerces-c/pull/2#discussion_r443127695



##
File path: CMakeLists.txt
##
@@ -177,8 +177,14 @@ install(
 # Process subdirectories
 add_subdirectory(doc)
 add_subdirectory(src)
-add_subdirectory(tests)
-add_subdirectory(samples)
+if (NOT (DEFINED XERCES_BUILD_FUZZERS))

Review comment:
   I am afraid I misunderstand your question though: Do you want just the 
if condition to change?





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



[GitHub] [xerces-c] viniul commented on a change in pull request #2: Commit fuzzer source code.

2020-06-20 Thread GitBox


viniul commented on a change in pull request #2:
URL: https://github.com/apache/xerces-c/pull/2#discussion_r443127487



##
File path: CMakeLists.txt
##
@@ -177,8 +177,14 @@ install(
 # Process subdirectories
 add_subdirectory(doc)
 add_subdirectory(src)
-add_subdirectory(tests)
-add_subdirectory(samples)
+if (NOT (DEFINED XERCES_BUILD_FUZZERS))
+  add_subdirectory(tests)
+  add_subdirectory(samples)
+endif()
+
+if ((DEFINED XERCES_BUILD_FUZZERS) OR (DEFINED XERCES_BUILD_FOR_OSS_FUZZ))

Review comment:
   Will do that, thanks!





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



[GitHub] [xerces-c] viniul commented on a change in pull request #2: Commit fuzzer source code.

2020-06-20 Thread GitBox


viniul commented on a change in pull request #2:
URL: https://github.com/apache/xerces-c/pull/2#discussion_r443127356



##
File path: build_fuzzer.sh
##
@@ -0,0 +1,8 @@
+#!/bin/bash

Review comment:
   Not necessarily needed, but I thought it might be helpful if someone 
does not want to figure out the build options by themselves. Should it go into 
the scripts sub-directory or be completely removed?





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



[GitHub] [xerces-c] rleigh-codelibre commented on pull request #2: Commit fuzzer source code.

2020-06-20 Thread GitBox


rleigh-codelibre commented on pull request #2:
URL: https://github.com/apache/xerces-c/pull/2#issuecomment-646988406


   @viniul I have done a preliminary review, please see the above comments.
   
   Please could you also answer the question regarding the licensing.  I see 
Google copyrights on some of the changes.  And presumably there are your own 
and/or your employer's copyrights in addition.  The necessary [corporate and 
individual copyright licensing 
agreements](https://www.apache.org/licenses/contributor-agreements.html) must 
be submitted before we are able to merge your work.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



[GitHub] [xerces-c] viniul commented on pull request #2: Commit fuzzer source code.

2020-06-20 Thread GitBox


viniul commented on pull request #2:
URL: https://github.com/apache/xerces-c/pull/2#issuecomment-646988283


   @rleigh-codelibre  Thank you very much for reviewing this PR. I will 
implement the suggested changes and open a new PR based on the current master.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



[GitHub] [xerces-c] rleigh-codelibre commented on a change in pull request #2: Commit fuzzer source code.

2020-06-20 Thread GitBox


rleigh-codelibre commented on a change in pull request #2:
URL: https://github.com/apache/xerces-c/pull/2#discussion_r443126284



##
File path: .gitignore
##
@@ -105,3 +105,6 @@ tests/scripts/*.log
 tests/scripts/*.trs
 tests/test-suite.log
 Testing/
+
+# Vincent
+build/

Review comment:
   This change should be kept private.  Please could you remove it from the 
PR?

##
File path: cmake/XercesIntTypes.cmake
##
@@ -58,14 +58,14 @@ set(HAVE_OFF_T ${SIZEOF_OFF_T})
 set(HAVE_SIZE_T ${SIZEOF_SIZE_T})
 set(HAVE_SSIZE_T ${SSIZEOF_SSIZE_T})
 set(HAVE_WCHAR_T ${WCHAROF_WCHAR_T})
-if(SIZEOF_SIZE_T)
+if(HAVE_SIZEOF_SIZE_T)

Review comment:
   I'm not sure where these changes have come from.  Is this a reversion of 
an earlier change?
   
   If the history is messy, it might be easiest to rebase all your changes onto 
the current `master` and start a new PR.

##
File path: CMakeLists.txt
##
@@ -177,8 +177,14 @@ install(
 # Process subdirectories
 add_subdirectory(doc)
 add_subdirectory(src)
-add_subdirectory(tests)
-add_subdirectory(samples)
+if (NOT (DEFINED XERCES_BUILD_FUZZERS))

Review comment:
   Why are these specifically excluded?  It might be nicer to only use the 
fuzzer-specific conditions on the fuzzer code itself.

##
File path: build_fuzzer.sh
##
@@ -0,0 +1,8 @@
+#!/bin/bash

Review comment:
   I don't see this file being used anywhere.  Does it really belong in the 
source tree?
   
   If it does belong, could it go into the `scripts` subdirectory alongside the 
CI scripts?

##
File path: src/xercesc/util/XMLChar.cpp
##
@@ -8837,7 +8837,7 @@ XMLByte XMLChar1_1::fgCharCharsTable1_1[0x1] =
 
 #include 
 
-static XMLCh gTmpCharTable[0x];

Review comment:
   I'm unsure about these any other code changes, above.  Are they 
intentional?
   
   If they are, please could you open separate PRs for them so we can keep code 
fixes separate from the fuzzer addition.

##
File path: CMakeLists.txt
##
@@ -177,8 +177,14 @@ install(
 # Process subdirectories
 add_subdirectory(doc)
 add_subdirectory(src)
-add_subdirectory(tests)
-add_subdirectory(samples)
+if (NOT (DEFINED XERCES_BUILD_FUZZERS))
+  add_subdirectory(tests)
+  add_subdirectory(samples)
+endif()
+
+if ((DEFINED XERCES_BUILD_FUZZERS) OR (DEFINED XERCES_BUILD_FOR_OSS_FUZZ))

Review comment:
   Additionally, rather than use XERCES_BUILD_FUZZERS, why not define an 
option `fuzzers` with `option()` defaulting to off, then you can just use 
`-Dfuzzers=ON`?

##
File path: CMakeLists.txt
##
@@ -177,8 +177,14 @@ install(
 # Process subdirectories
 add_subdirectory(doc)
 add_subdirectory(src)
-add_subdirectory(tests)
-add_subdirectory(samples)
+if (NOT (DEFINED XERCES_BUILD_FUZZERS))
+  add_subdirectory(tests)
+  add_subdirectory(samples)
+endif()
+
+if ((DEFINED XERCES_BUILD_FUZZERS) OR (DEFINED XERCES_BUILD_FOR_OSS_FUZZ))

Review comment:
   Please always include all subdirectories, and place the above 
conditionals around the logic inside the file.  This ensures the logic is 
evaluated whatever the cmake options, and helps to prevent regressions.

##
File path: fuzzers/CMakeLists.txt
##
@@ -0,0 +1,90 @@
+# CMake build for xerces-c
+#
+# Written by Roger Leigh 
+#
+# Licensed to the Apache Software Foundation (ASF) under one or more
+# contributor license agreements.  See the NOTICE file distributed with
+# this work for additional information regarding copyright ownership.
+# The ASF licenses this file to You under the Apache License, Version 2.0
+# (the "License"); you may not use this file except in compliance with
+# the License.  You may obtain a copy of the License at
+#
+#  http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+
+# Definitions required for building
+add_definitions(
+  -DHAVE_CONFIG_H=1

Review comment:
   If this is necessary, I think target_compile_definitions would be more 
appropriate, rather than setting it globally.





This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



[GitHub] [xerces-c] viniul commented on pull request #2: Commit fuzzer source code.

2020-06-20 Thread GitBox


viniul commented on pull request #2:
URL: https://github.com/apache/xerces-c/pull/2#issuecomment-646984925


   @rleigh-codelibre  I updated the PR to also includes the changes for CMake. 
Is this sufficient to get the PR merge dfor now? I f so, let me create a new 
clean PR based on the currnet master branch of xeres-c



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



[GitHub] [xerces-c] viniul edited a comment on pull request #2: Commit fuzzer source code.

2020-06-20 Thread GitBox


viniul edited a comment on pull request #2:
URL: https://github.com/apache/xerces-c/pull/2#issuecomment-646984925


   @rleigh-codelibre  I updated the PR to also includes the changes for CMake. 
Is this sufficient to get the PR merge dfor now? I f so, let me create a new 
clean PR based on the current master branch of xeres-c



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



[GitHub] [xerces-c] rleigh-codelibre commented on pull request #2: Commit fuzzer source code.

2020-06-20 Thread GitBox


rleigh-codelibre commented on pull request #2:
URL: https://github.com/apache/xerces-c/pull/2#issuecomment-646975989


   @viniul The addition of a test looks fairly low-risk in terms of wider 
impact on the project.
   
   Has the necessary Apache ICLA and/or company CLA been done?
   
   On the integration side, it would be nice to have this added to the 
CMakeLists.txt as for the other tests, and likewise to Makefile.am.  If the 
fuzzing is long-running, I would suggest not adding to CTest so that it isn't 
part of the regular integration testing.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



[GitHub] [xerces-c] viniul commented on pull request #2: Commit fuzzer source code.

2020-06-20 Thread GitBox


viniul commented on pull request #2:
URL: https://github.com/apache/xerces-c/pull/2#issuecomment-646973122


   CC @rleigh-codelibre As described above, this PR adds some fuzzing harnesses 
for xerces, which we (@bshastry and me) think would be nice to have in the 
master branch, because it allows continuous fuzzing via oss-fuzz and also makes 
it very easy for developers to fuzz-test their code prior to the release. 
Should I post this to the mailing list?



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



3.3.0 Issues migrated to 4.0.0

2020-06-20 Thread Roger Leigh

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

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



Roger



[jira] [Updated] (XERCESC-2141) Enable C++11/14/17 with autoconf build and CMake build

2020-06-20 Thread Roger Leigh (Jira)


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

Roger Leigh updated XERCESC-2141:
-
Fix Version/s: (was: 3.3.0)
   4.0.0

> Enable C++11/14/17 with autoconf build and CMake build
> --
>
> Key: XERCESC-2141
> URL: https://issues.apache.org/jira/browse/XERCESC-2141
> Project: Xerces-C++
>  Issue Type: Improvement
>  Components: Build
>Reporter: Roger Leigh
>Assignee: Roger Leigh
>Priority: Major
>  Labels: autoconf, build, c++11, c++14, c++17
> Fix For: 4.0.0
>
> Attachments: 0001-autoconf-Enable-C-14-or-C-11-when-available.patch
>
>
> The CMake build will try to put the compiler in C++14 mode, falling back to 
> C++11 then C++98.  The autoconf build doesn't do this, and the attached patch 
> makes the behaviour match so both build systems will use the same fallbacks.
> Current compilers default to C++14.  Very old compilers have no support for 
> C++11 or C++14.  But compilers in between support it, but not by default.  
> This adds the feature tests to check for such support and enable it when 
> available.
> The CMake C++ standard support is user-configurable by setting the 
> CMAKE_CXX_STANDARD setting.  Autoconf doesn't provide any way to do this, so 
> the feature enabling isn't explicitly overridable.  I'm not sure if that's 
> too problematic.  The main compatibility concern might be if this causes an 
> ABI break with use of C++11/14 library features like the new string type.  
> However, we aren't making use of any of these features.  The main change 
> would be the XMLCh type switch from uint16_t to char16_t.  I'm not sure what 
> the Xerces policy for such changes has been in the past.  Any thoughts?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (XERCESC-2202) Update version of master branch to 3.3.0

2020-06-20 Thread Roger Leigh (Jira)


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

Roger Leigh updated XERCESC-2202:
-
Fix Version/s: (was: 3.3.0)
   4.0.0

> Update version of master branch to 3.3.0
> 
>
> Key: XERCESC-2202
> URL: https://issues.apache.org/jira/browse/XERCESC-2202
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Miscellaneous
>Affects Versions: 3.3.0
>Reporter: Roger Leigh
>Assignee: Roger Leigh
>Priority: Major
> Fix For: 4.0.0
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (XERCESC-2201) Update Travis-CI image in use

2020-06-20 Thread Roger Leigh (Jira)


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

Roger Leigh updated XERCESC-2201:
-
Fix Version/s: (was: 3.3.0)
   4.0.0

> Update Travis-CI image in use
> -
>
> Key: XERCESC-2201
> URL: https://issues.apache.org/jira/browse/XERCESC-2201
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Miscellaneous
>Affects Versions: 3.3.0
>Reporter: Roger Leigh
>Assignee: Roger Leigh
>Priority: Major
> Fix For: 4.0.0
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> Update image to use current image e.g. Ubuntu 20.04 LTS, which should see us 
> supported for some time into the future.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (XERCESC-2200) Update AppVeyor image in use

2020-06-20 Thread Roger Leigh (Jira)


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

Roger Leigh updated XERCESC-2200:
-
Fix Version/s: (was: 3.3.0)
   4.0.0

> Update AppVeyor image in use
> 
>
> Key: XERCESC-2200
> URL: https://issues.apache.org/jira/browse/XERCESC-2200
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Miscellaneous
>Affects Versions: 3.3.0
>Reporter: Roger Leigh
>Assignee: Roger Leigh
>Priority: Major
> Fix For: 4.0.0
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> AppVeyor images haven't been upgraded for some time.  Update to newer image 
> with VS2019 or VS2017, and switch to vcpkg for ICU and CURL dependencies etc. 
> which are now provided directly by vcpkg in the AppVeyor images.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (XERCESC-2203) MingGW time functions are broken

2020-06-20 Thread Roger Leigh (Jira)


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

Roger Leigh updated XERCESC-2203:
-
Fix Version/s: (was: 3.3.0)
   4.0.0

> MingGW time functions are broken
> 
>
> Key: XERCESC-2203
> URL: https://issues.apache.org/jira/browse/XERCESC-2203
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 3.3.0
>Reporter: Roger Leigh
>Assignee: Roger Leigh
>Priority: Major
> Fix For: 4.0.0
>
>
> {noformat}
> C:/projects/xerces-c/src/xercesc/util/XMLDateTime.cpp:583:29: error: use of 
> undeclared identifier 'timezone'
> return mktime() - timezone;
> {noformat}
> Newer versions of MinGW have added functions which were previously missing, 
> like gmtime_r and localtime_r.  It's possible the autodetection logic is 
> incomplete and it's not using the correct ifdefs.  For Xalan-C, I added 
> additional feature detection and this solved the problem and will work with 
> old or new MinGW versions.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (XERCESC-2210) Remove XERCES_NO_MATCHING_DELETE_OPERATOR

2020-06-20 Thread Roger Leigh (Jira)


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

Roger Leigh updated XERCESC-2210:
-
Fix Version/s: (was: 3.3.0)
   4.0.0

> Remove XERCES_NO_MATCHING_DELETE_OPERATOR
> -
>
> Key: XERCESC-2210
> URL: https://issues.apache.org/jira/browse/XERCESC-2210
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Build, Miscellaneous
>Affects Versions: 3.3.0
>Reporter: Roger Leigh
>Assignee: Roger Leigh
>Priority: Major
> Fix For: 4.0.0
>
>
> XERCES_NO_MATCHING_DELETE_OPERATOR is checked for by both autoconf and cmake. 
>  It is used in XMemory and DOMDocumentImpl.
> Any conforming compiler from this century should be perfectly capable of 
> providing a proper operator delete, since it's a fundamental requirement for 
> all the standard containers.  This check is thoroughly obsolete.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



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

2020-06-20 Thread Roger Leigh (Jira)


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

Roger Leigh updated XERCESC-2208:
-
Fix Version/s: (was: 3.3.0)
   4.0.0

> Rationalise XercesIntTypes
> --
>
> Key: XERCESC-2208
> URL: https://issues.apache.org/jira/browse/XERCESC-2208
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Miscellaneous
>Affects Versions: 3.3.0
>Reporter: Roger Leigh
>Assignee: Roger Leigh
>Priority: Major
> Fix For: 4.0.0
>
>
> We currently have multiple fallbacks for int types from cstdint, stdint.h, 
> inttypes.h etc.  However, if we require cstdint then we have most of the 
> basic types guaranteed to be provided, and most of the logic to handle the 
> fallbacks can be eliminated entirely.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (XERCESC-2205) Require std::mutex and std::thread

2020-06-20 Thread Roger Leigh (Jira)


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

Roger Leigh updated XERCESC-2205:
-
Fix Version/s: (was: 3.3.0)
   4.0.0

> Require std::mutex and std::thread
> --
>
> Key: XERCESC-2205
> URL: https://issues.apache.org/jira/browse/XERCESC-2205
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Miscellaneous
>Affects Versions: 3.3.0
>Reporter: Roger Leigh
>Assignee: Roger Leigh
>Priority: Major
> Fix For: 4.0.0
>
>
> Replace the existing MutexManager with the standard library implementation.  
> This is essentially going to be pthreads or Windows threads under the hood, 
> so it's effectively replacing PosixMutexManager and WindowsMutexManager with 
> a single standard replacement.  This is currently StdMutexMgr, but rather 
> than using the MutexManager abstraction, we would be using the standard types 
> directly.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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



[jira] [Updated] (XERCESC-2207) Rationalise network accessors

2020-06-20 Thread Roger Leigh (Jira)


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

Roger Leigh updated XERCESC-2207:
-
Fix Version/s: (was: 3.3.0)
   4.0.0

> Rationalise network accessors
> -
>
> Key: XERCESC-2207
> URL: https://issues.apache.org/jira/browse/XERCESC-2207
> Project: Xerces-C++
>  Issue Type: Bug
>  Components: Miscellaneous
>Affects Versions: 3.3.0
>Reporter: Roger Leigh
>Priority: Major
> Fix For: 4.0.0
>
>
> We currently support four netaccessors: curl, winsock, socket and cfurl.  And 
> also "none" if network support is disabled.
> This makes the test matrix quite large.  Additionally, with the recent push 
> to use HTTPS everywhere, I wonder about the dangers of Xerces using its own 
> plain HTTP implementation over sockets without any SSL support.
> Would dropping socket and winsock, and requiring curl or cfurl make sense?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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