[jira] [Commented] (XERCESC-2193) Validation error for prefix declaration on element whose value uses a prefix
[ https://issues.apache.org/jira/browse/XERCESC-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1707#comment-1707 ] Herm Fischer commented on XERCESC-2193: --- Thank you for responding! And for suggesting a proper test case. This is in an XBRL schema's appinfo, which is snipped in xsd processing from the schema annotation into a string buffer be parsed/validated as xml isolated from the xsd container. When first isolating to a tiny test case in an ordinary xml file the xmlns on the consuming element works fine. So I need to do some more tracing to create the misbehaving test case, may be a few days before I can get to it. > Validation error for prefix declaration on element whose value uses a prefix > > > Key: XERCESC-2193 > URL: https://issues.apache.org/jira/browse/XERCESC-2193 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (XML Schema) >Affects Versions: 3.2.2 > Environment: Linux >Reporter: Herm Fischer >Priority: Major > > Xerces schema validation reports the prefix is undefined when QName content > of an element is using a prefix defined on the element (works fine with > Xerces-J, etc). > http://example.com/this;>this:someArc > validation message: undefined prefix in QName value 'this:someArc' > Is there a parameter, usage pattern, or code patch which will make this > validate cleanly? (isPrefixUnknown seems to look in element stack instead of > looking first at current element?) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2190) deprecated GetVersionEx
[
https://issues.apache.org/jira/browse/XERCESC-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17073112#comment-17073112
]
Scott Cantor commented on XERCESC-2190:
---
Officially, there's no question here, we're not supporting any EOL Windows
versions. I'm not trying to waffle on that at all. I would suggest if there's a
3.3 you just pull the offending code at that point if it makes life easier.
Re: RHEL, my RPMs have to build clean and install clean on the stock platform.
I do think all the C++ is now in my hands, so the install might be clean, but
my build at present doesn't have any ability to incorporate a non-stock
compiler at build time. That may change but not likely any sooner than November
when it goes EOL.
> deprecated GetVersionEx
> ---
>
> Key: XERCESC-2190
> URL: https://issues.apache.org/jira/browse/XERCESC-2190
> Project: Xerces-C++
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Aleksey Dobrunov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hello.
> *"GetVersionEx* may be altered or unavailable for releases after Windows 8.1.
> Instead, use the [Version Helper
> functions"|https://docs.microsoft.com/windows/desktop/SysInfo/version-helper-apis]
>
> [https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getversionexa]
> .
> {code:java}
> C:\Work\code\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(323):
> warning C4996: 'GetVersionExA': was declared deprecated
> C:\Program Files (x86)\Windows
> Kits\10\include\10.0.18362.0\um\sysinfoapi.h(387): note: see declaration of
> 'GetVersionExA'
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2190) deprecated GetVersionEx
[
https://issues.apache.org/jira/browse/XERCESC-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17073107#comment-17073107
]
Roger Leigh commented on XERCESC-2190:
--
Yes, I was surprised when I went to check on Server 2008 R2 in more detail.
It's not that long since I had to support it either.
For RHEL6, I used to use devtoolset-8 for development on this platform. It's
definitely a viable option for users who need to target it.
I'm certainly not suggesting deliberately ripping support for older platform
out just for the sake of it. But I do feel that given the development
constraints we are working under, it would be good to be realistic about what
is effectively supportable, and what is absolutely unsupportable, and there are
quite a few platforms which I do feel are not reasonable to support in any
capacity. I'd say Windows Vista and below fall in that category. Windows 7 is
hanging on by a thread but realistically I can't test on it any longer; I've
been forced onto Windows 10 and VS2017/VS2019, and Server 2016. AppVeyor can
be used to test on other compilers up to a point, but debugging and more
extensive testing aren't possible.
> deprecated GetVersionEx
> ---
>
> Key: XERCESC-2190
> URL: https://issues.apache.org/jira/browse/XERCESC-2190
> Project: Xerces-C++
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Aleksey Dobrunov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hello.
> *"GetVersionEx* may be altered or unavailable for releases after Windows 8.1.
> Instead, use the [Version Helper
> functions"|https://docs.microsoft.com/windows/desktop/SysInfo/version-helper-apis]
>
> [https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getversionexa]
> .
> {code:java}
> C:\Work\code\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(323):
> warning C4996: 'GetVersionExA': was declared deprecated
> C:\Program Files (x86)\Windows
> Kits\10\include\10.0.18362.0\um\sysinfoapi.h(387): note: see declaration of
> 'GetVersionExA'
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2177) invalid windows version check for `onXPOrLater`
[
https://issues.apache.org/jira/browse/XERCESC-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17073098#comment-17073098
]
Roger Leigh commented on XERCESC-2177:
--
As mentioned on XERCESC-2190 I think we would be better off deleting use of
this function entirely and assuming that we're on a recent enough Windows
platform. Since the affected versions are over two decades old and thoroughly
obsolete, and no supported development environment can target them, that's a
fairly safe assumption to make.
> invalid windows version check for `onXPOrLater`
> ---
>
> Key: XERCESC-2177
> URL: https://issues.apache.org/jira/browse/XERCESC-2177
> Project: Xerces-C++
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 3.2.0, 3.2.1, 3.2.2
> Environment: win10 x64
>Reporter: Vvv
>Assignee: Alberto Massari
>Priority: Minor
> Labels: beginner, easyfix, windows
> Fix For: 3.2.3
>
>
> in
> {{xerces-c-3.2.2\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp:324}}
>
> {{ if ((OSVer.dwPlatformId == VER_PLATFORM_WIN32_NT) &&}}
> {{ ((OSVer.dwMajorVersion == 5) && (OSVer.dwMinorVersion > 0)))}}
> {{ {}}
> {{ onXPOrLater = true;}}
> {{ }}}
> on win10 {{OSVer.dwMajorVersion = 6}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
Xerces-C 3.2.3 timeline
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. -- Scott - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2177) invalid windows version check for `onXPOrLater`
[
https://issues.apache.org/jira/browse/XERCESC-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Cantor updated XERCESC-2177:
--
Remaining Estimate: (was: 5m)
Original Estimate: (was: 5m)
> invalid windows version check for `onXPOrLater`
> ---
>
> Key: XERCESC-2177
> URL: https://issues.apache.org/jira/browse/XERCESC-2177
> Project: Xerces-C++
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 3.2.0, 3.2.1, 3.2.2
> Environment: win10 x64
>Reporter: Vvv
>Assignee: Alberto Massari
>Priority: Minor
> Labels: beginner, easyfix, windows
> Fix For: 3.2.3
>
>
> in
> {{xerces-c-3.2.2\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp:324}}
>
> {{ if ((OSVer.dwPlatformId == VER_PLATFORM_WIN32_NT) &&}}
> {{ ((OSVer.dwMajorVersion == 5) && (OSVer.dwMinorVersion > 0)))}}
> {{ {}}
> {{ onXPOrLater = true;}}
> {{ }}}
> on win10 {{OSVer.dwMajorVersion = 6}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2179) access violation in win32transservice.cpp with 64 bit compile
[ https://issues.apache.org/jira/browse/XERCESC-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor updated XERCESC-2179: -- Fix Version/s: (was: 3.2.3) > access violation in win32transservice.cpp with 64 bit compile > - > > Key: XERCESC-2179 > URL: https://issues.apache.org/jira/browse/XERCESC-2179 > Project: Xerces-C++ > Issue Type: Bug > Components: DOM >Affects Versions: 3.2.2 >Reporter: martin goodall >Assignee: Alberto Massari >Priority: Blocker > Attachments: Win32TransService.cpp > > > calls to ::Reg... to get registry info are passing in stack variables that > are 8 bytes long into functions that overwrite 16 bytes, causing memory > overwrite and very random segs. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2160) Postpone freeing the memory being used by CURL
[ https://issues.apache.org/jira/browse/XERCESC-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor resolved XERCESC-2160. --- Resolution: Duplicate This has been patched, it was the same fix as the linked issue. > Postpone freeing the memory being used by CURL > -- > > Key: XERCESC-2160 > URL: https://issues.apache.org/jira/browse/XERCESC-2160 > Project: Xerces-C++ > Issue Type: Bug > Components: Utilities >Affects Versions: 3.2.0, 3.2.1, 3.2.2 > Environment: Ubuntu 16.04 LTS >Reporter: Zane U. Ji >Assignee: Scott Cantor >Priority: Major > Fix For: 3.2.3 > > Attachments: 0001-Postpone-freeing-the-memory-being-used-by-CURL.patch > > > Some sites require a valid User-Agent HTTP header. However, xerces-c crashes > when a HTTP header is set. The patch fixes the problem. -- 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] [Closed] (XERCESC-2160) Postpone freeing the memory being used by CURL
[ https://issues.apache.org/jira/browse/XERCESC-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor closed XERCESC-2160. - > Postpone freeing the memory being used by CURL > -- > > Key: XERCESC-2160 > URL: https://issues.apache.org/jira/browse/XERCESC-2160 > Project: Xerces-C++ > Issue Type: Bug > Components: Utilities >Affects Versions: 3.2.0, 3.2.1, 3.2.2 > Environment: Ubuntu 16.04 LTS >Reporter: Zane U. Ji >Assignee: Scott Cantor >Priority: Major > Fix For: 3.2.3 > > Attachments: 0001-Postpone-freeing-the-memory-being-used-by-CURL.patch > > > Some sites require a valid User-Agent HTTP header. However, xerces-c crashes > when a HTTP header is set. The patch fixes the problem. -- 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-1963) Custom HTTP headers missing with CURL NetAccessor
[ https://issues.apache.org/jira/browse/XERCESC-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17073043#comment-17073043 ] Scott Cantor commented on XERCESC-1963: --- Applied to both branches. Note this changes the ABI but we have agreed to treat the truly internal classes as safe to change in a patch as long as they're not embedded in any public classes. > Custom HTTP headers missing with CURL NetAccessor > -- > > Key: XERCESC-1963 > URL: https://issues.apache.org/jira/browse/XERCESC-1963 > Project: Xerces-C++ > Issue Type: Bug > Components: Utilities >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 > Environment: Xerces-c 3.1.1 > curl_version: libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3 > Mac OS X 10.6.7, i686-apple-darwin10-g++-4.2.1 >Reporter: Eric Swalens >Assignee: Scott Cantor >Priority: Minor > Labels: patch > Fix For: 3.2.3 > > Attachments: CurlURLInputStream-headers-0.1.patch > > > It seems that the custom headers set using XMLNetHTTPInfo are missing from > the actual HTTP request when the CURLNetAccessor is used. The > SocketNetAccessor does not show this problem. > The headerList in the CurlURLInputStream constructor is correctly built but > from what I understand of the CURL documentation the list cannot be freed > until the GET request has been made. Currently the list feed right after > setting the CURLOPT_HTTPHEADER. Delaying the call curl_slist_free_all to the > destructor solves the issue (patch attached). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-1963) Custom HTTP headers missing with CURL NetAccessor
[ https://issues.apache.org/jira/browse/XERCESC-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor resolved XERCESC-1963. --- Resolution: Fixed > Custom HTTP headers missing with CURL NetAccessor > -- > > Key: XERCESC-1963 > URL: https://issues.apache.org/jira/browse/XERCESC-1963 > Project: Xerces-C++ > Issue Type: Bug > Components: Utilities >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 > Environment: Xerces-c 3.1.1 > curl_version: libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3 > Mac OS X 10.6.7, i686-apple-darwin10-g++-4.2.1 >Reporter: Eric Swalens >Assignee: Scott Cantor >Priority: Minor > Labels: patch > Fix For: 3.2.3 > > Attachments: CurlURLInputStream-headers-0.1.patch > > > It seems that the custom headers set using XMLNetHTTPInfo are missing from > the actual HTTP request when the CURLNetAccessor is used. The > SocketNetAccessor does not show this problem. > The headerList in the CurlURLInputStream constructor is correctly built but > from what I understand of the CURL documentation the list cannot be freed > until the GET request has been made. Currently the list feed right after > setting the CURLOPT_HTTPHEADER. Delaying the call curl_slist_free_all to the > destructor solves the issue (patch attached). -- 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] [Closed] (XERCESC-1963) Custom HTTP headers missing with CURL NetAccessor
[ https://issues.apache.org/jira/browse/XERCESC-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor closed XERCESC-1963. - > Custom HTTP headers missing with CURL NetAccessor > -- > > Key: XERCESC-1963 > URL: https://issues.apache.org/jira/browse/XERCESC-1963 > Project: Xerces-C++ > Issue Type: Bug > Components: Utilities >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 > Environment: Xerces-c 3.1.1 > curl_version: libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3 > Mac OS X 10.6.7, i686-apple-darwin10-g++-4.2.1 >Reporter: Eric Swalens >Assignee: Scott Cantor >Priority: Minor > Labels: patch > Fix For: 3.2.3 > > Attachments: CurlURLInputStream-headers-0.1.patch > > > It seems that the custom headers set using XMLNetHTTPInfo are missing from > the actual HTTP request when the CURLNetAccessor is used. The > SocketNetAccessor does not show this problem. > The headerList in the CurlURLInputStream constructor is correctly built but > from what I understand of the CURL documentation the list cannot be freed > until the GET request has been made. Currently the list feed right after > setting the CURLOPT_HTTPHEADER. Delaying the call curl_slist_free_all to the > destructor solves the issue (patch attached). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[xerces-c] branch xerces-3.2 updated: XERCESC-1963 - Custom HTTP headers missing with CURL NetAccessor
This is an automated email from the ASF dual-hosted git repository.
scantor pushed a commit to branch xerces-3.2
in repository https://gitbox.apache.org/repos/asf/xerces-c.git
The following commit(s) were added to refs/heads/xerces-3.2 by this push:
new d38587f XERCESC-1963 - Custom HTTP headers missing with CURL
NetAccessor
d38587f is described below
commit d38587f35be4e3fd668fcf87391f9de464f4d4e4
Author: Scott Cantor
AuthorDate: Wed Apr 1 13:55:07 2020 -0400
XERCESC-1963 - Custom HTTP headers missing with CURL NetAccessor
---
.../util/NetAccessors/Curl/CurlURLInputStream.cpp | 58 +++---
.../util/NetAccessors/Curl/CurlURLInputStream.hpp | 19 +++
2 files changed, 39 insertions(+), 38 deletions(-)
diff --git a/src/xercesc/util/NetAccessors/Curl/CurlURLInputStream.cpp
b/src/xercesc/util/NetAccessors/Curl/CurlURLInputStream.cpp
index 8d9befd..5ed6593 100644
--- a/src/xercesc/util/NetAccessors/Curl/CurlURLInputStream.cpp
+++ b/src/xercesc/util/NetAccessors/Curl/CurlURLInputStream.cpp
@@ -56,6 +56,7 @@ XERCES_CPP_NAMESPACE_BEGIN
CurlURLInputStream::CurlURLInputStream(const XMLURL& urlSource, const
XMLNetHTTPInfo* httpInfo/*=0*/)
: fMulti(0)
, fEasy(0)
+ , fHeadersList(0)
, fMemoryManager(urlSource.getMemoryManager())
, fURLSource(urlSource)
, fTotalBytesRead(0)
@@ -69,23 +70,23 @@ CurlURLInputStream::CurlURLInputStream(const XMLURL&
urlSource, const XMLNetHTTP
, fPayloadLen(0)
, fContentType(0)
{
- // Allocate the curl multi handle
- fMulti = curl_multi_init();
+// Allocate the curl multi handle
+fMulti = curl_multi_init();
- // Allocate the curl easy handle
- fEasy = curl_easy_init();
+// Allocate the curl easy handle
+fEasy = curl_easy_init();
- // Set URL option
+// Set URL option
TranscodeToStr url(fURLSource.getURLText(), "ISO8859-1", fMemoryManager);
- curl_easy_setopt(fEasy, CURLOPT_URL, (char*)url.str());
+curl_easy_setopt(fEasy, CURLOPT_URL, (char*)url.str());
// Set up a way to recieve the data
- curl_easy_setopt(fEasy, CURLOPT_WRITEDATA, this);
// Pass this pointer to write function
- curl_easy_setopt(fEasy, CURLOPT_WRITEFUNCTION, staticWriteCallback);
// Our static write function
+curl_easy_setopt(fEasy, CURLOPT_WRITEDATA, this);
// Pass this pointer to write function
+curl_easy_setopt(fEasy, CURLOPT_WRITEFUNCTION, staticWriteCallback);
// Our static write function
- // Do redirects
- curl_easy_setopt(fEasy, CURLOPT_FOLLOWLOCATION, (long)1);
- curl_easy_setopt(fEasy, CURLOPT_MAXREDIRS, (long)6);
+// Do redirects
+curl_easy_setopt(fEasy, CURLOPT_FOLLOWLOCATION, (long)1);
+curl_easy_setopt(fEasy, CURLOPT_MAXREDIRS, (long)6);
// Add username and password if authentication is required
const XMLCh *username = urlSource.getUser();
@@ -117,8 +118,6 @@ CurlURLInputStream::CurlURLInputStream(const XMLURL&
urlSource, const XMLNetHTTP
// Add custom headers
if(httpInfo->fHeaders) {
-struct curl_slist *headersList = 0;
-
const char *headersBuf = httpInfo->fHeaders;
const char *headersBufEnd = httpInfo->fHeaders +
httpInfo->fHeadersLen;
@@ -133,7 +132,7 @@ CurlURLInputStream::CurlURLInputStream(const XMLURL&
urlSource, const XMLNetHTTP
memcpy(header.get(), headerStart, length);
header.get()[length] = 0;
-headersList = curl_slist_append(headersList, header.get());
+fHeadersList = curl_slist_append(fHeadersList,
header.get());
headersBuf += 2;
headerStart = headersBuf;
@@ -141,8 +140,7 @@ CurlURLInputStream::CurlURLInputStream(const XMLURL&
urlSource, const XMLNetHTTP
}
++headersBuf;
}
-curl_easy_setopt(fEasy, CURLOPT_HTTPHEADER, headersList);
-curl_slist_free_all(headersList);
+curl_easy_setopt(fEasy, CURLOPT_HTTPHEADER, fHeadersList);
}
// Set up the payload
@@ -155,16 +153,16 @@ CurlURLInputStream::CurlURLInputStream(const XMLURL&
urlSource, const XMLNetHTTP
}
}
- // Add easy handle to the multi stack
- curl_multi_add_handle(fMulti, fEasy);
+// Add easy handle to the multi stack
+curl_multi_add_handle(fMulti, fEasy);
// Start reading, to get the content type
- while(fBufferHeadPtr == fBuffer)
- {
- int runningHandles = 0;
+while(fBufferHeadPtr == fBuffer)
+{
+ int runningHandles = 0;
readMore();
- if(runningHandles == 0) break;
- }
+ if(runningHandles == 0) break;
+}
// Find the content type
char *contentType8 = 0;
@@ -176,16 +174,18 @@
[xerces-c] branch master updated: XERCESC-1963 - Custom HTTP headers missing with CURL NetAccessor
This is an automated email from the ASF dual-hosted git repository.
scantor pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/xerces-c.git
The following commit(s) were added to refs/heads/master by this push:
new d8881d6 XERCESC-1963 - Custom HTTP headers missing with CURL
NetAccessor
d8881d6 is described below
commit d8881d69a3993399179f50f1b76ac3aa8d830774
Author: Scott Cantor
AuthorDate: Wed Apr 1 13:55:07 2020 -0400
XERCESC-1963 - Custom HTTP headers missing with CURL NetAccessor
---
.../util/NetAccessors/Curl/CurlURLInputStream.cpp | 58 +++---
.../util/NetAccessors/Curl/CurlURLInputStream.hpp | 19 +++
2 files changed, 39 insertions(+), 38 deletions(-)
diff --git a/src/xercesc/util/NetAccessors/Curl/CurlURLInputStream.cpp
b/src/xercesc/util/NetAccessors/Curl/CurlURLInputStream.cpp
index 8d9befd..5ed6593 100644
--- a/src/xercesc/util/NetAccessors/Curl/CurlURLInputStream.cpp
+++ b/src/xercesc/util/NetAccessors/Curl/CurlURLInputStream.cpp
@@ -56,6 +56,7 @@ XERCES_CPP_NAMESPACE_BEGIN
CurlURLInputStream::CurlURLInputStream(const XMLURL& urlSource, const
XMLNetHTTPInfo* httpInfo/*=0*/)
: fMulti(0)
, fEasy(0)
+ , fHeadersList(0)
, fMemoryManager(urlSource.getMemoryManager())
, fURLSource(urlSource)
, fTotalBytesRead(0)
@@ -69,23 +70,23 @@ CurlURLInputStream::CurlURLInputStream(const XMLURL&
urlSource, const XMLNetHTTP
, fPayloadLen(0)
, fContentType(0)
{
- // Allocate the curl multi handle
- fMulti = curl_multi_init();
+// Allocate the curl multi handle
+fMulti = curl_multi_init();
- // Allocate the curl easy handle
- fEasy = curl_easy_init();
+// Allocate the curl easy handle
+fEasy = curl_easy_init();
- // Set URL option
+// Set URL option
TranscodeToStr url(fURLSource.getURLText(), "ISO8859-1", fMemoryManager);
- curl_easy_setopt(fEasy, CURLOPT_URL, (char*)url.str());
+curl_easy_setopt(fEasy, CURLOPT_URL, (char*)url.str());
// Set up a way to recieve the data
- curl_easy_setopt(fEasy, CURLOPT_WRITEDATA, this);
// Pass this pointer to write function
- curl_easy_setopt(fEasy, CURLOPT_WRITEFUNCTION, staticWriteCallback);
// Our static write function
+curl_easy_setopt(fEasy, CURLOPT_WRITEDATA, this);
// Pass this pointer to write function
+curl_easy_setopt(fEasy, CURLOPT_WRITEFUNCTION, staticWriteCallback);
// Our static write function
- // Do redirects
- curl_easy_setopt(fEasy, CURLOPT_FOLLOWLOCATION, (long)1);
- curl_easy_setopt(fEasy, CURLOPT_MAXREDIRS, (long)6);
+// Do redirects
+curl_easy_setopt(fEasy, CURLOPT_FOLLOWLOCATION, (long)1);
+curl_easy_setopt(fEasy, CURLOPT_MAXREDIRS, (long)6);
// Add username and password if authentication is required
const XMLCh *username = urlSource.getUser();
@@ -117,8 +118,6 @@ CurlURLInputStream::CurlURLInputStream(const XMLURL&
urlSource, const XMLNetHTTP
// Add custom headers
if(httpInfo->fHeaders) {
-struct curl_slist *headersList = 0;
-
const char *headersBuf = httpInfo->fHeaders;
const char *headersBufEnd = httpInfo->fHeaders +
httpInfo->fHeadersLen;
@@ -133,7 +132,7 @@ CurlURLInputStream::CurlURLInputStream(const XMLURL&
urlSource, const XMLNetHTTP
memcpy(header.get(), headerStart, length);
header.get()[length] = 0;
-headersList = curl_slist_append(headersList, header.get());
+fHeadersList = curl_slist_append(fHeadersList,
header.get());
headersBuf += 2;
headerStart = headersBuf;
@@ -141,8 +140,7 @@ CurlURLInputStream::CurlURLInputStream(const XMLURL&
urlSource, const XMLNetHTTP
}
++headersBuf;
}
-curl_easy_setopt(fEasy, CURLOPT_HTTPHEADER, headersList);
-curl_slist_free_all(headersList);
+curl_easy_setopt(fEasy, CURLOPT_HTTPHEADER, fHeadersList);
}
// Set up the payload
@@ -155,16 +153,16 @@ CurlURLInputStream::CurlURLInputStream(const XMLURL&
urlSource, const XMLNetHTTP
}
}
- // Add easy handle to the multi stack
- curl_multi_add_handle(fMulti, fEasy);
+// Add easy handle to the multi stack
+curl_multi_add_handle(fMulti, fEasy);
// Start reading, to get the content type
- while(fBufferHeadPtr == fBuffer)
- {
- int runningHandles = 0;
+while(fBufferHeadPtr == fBuffer)
+{
+ int runningHandles = 0;
readMore();
- if(runningHandles == 0) break;
- }
+ if(runningHandles == 0) break;
+}
// Find the content type
char *contentType8 = 0;
@@ -176,16 +174,18 @@
[jira] [Commented] (XERCESC-2190) deprecated GetVersionEx
[
https://issues.apache.org/jira/browse/XERCESC-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17073036#comment-17073036
]
Scott Cantor commented on XERCESC-2190:
---
Yes, I'm very clear about what's supported and it's a really small list, and
the Windows policy is exactly that.
For the record, Server 2008 is not EOL. It's fully supported in Azure, which
means there's nothing about it that's not supported other than the blackmail by
MS to move people to their cloud. As a platform, nothing's really changed for
my projects, it remains supported.
I personally only support the compiler I use, which is 2017 at the moment. As a
project I don't have an opinion other than to say I can't spend any time on
issues on any other compiler, so either somebody else has to or it needs to be
clear that that's all that's supported.
My point re: this change is just that I don't see a huge win or any sort of
"cleanup" gained from ripping the code out and breaking the unsupported
versions. I'm not saying we should support older versions, but that's not the
same as breaking them. But if you feel strongly I'm fine with it.
Re: C++11, RHEL6 is something I have to support and it doesn't have a GCC new
enough. I build on some older but don't officially support them so breaking
them isn't fatal but I do have to support 6. It does sunset this year though so
that may not be a dealbreaker.
> deprecated GetVersionEx
> ---
>
> Key: XERCESC-2190
> URL: https://issues.apache.org/jira/browse/XERCESC-2190
> Project: Xerces-C++
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Aleksey Dobrunov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hello.
> *"GetVersionEx* may be altered or unavailable for releases after Windows 8.1.
> Instead, use the [Version Helper
> functions"|https://docs.microsoft.com/windows/desktop/SysInfo/version-helper-apis]
>
> [https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getversionexa]
> .
> {code:java}
> C:\Work\code\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(323):
> warning C4996: 'GetVersionExA': was declared deprecated
> C:\Program Files (x86)\Windows
> Kits\10\include\10.0.18362.0\um\sysinfoapi.h(387): note: see declaration of
> 'GetVersionExA'
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Issue Comment Deleted] (XERCESC-2190) deprecated GetVersionEx
[
https://issues.apache.org/jira/browse/XERCESC-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Cantor updated XERCESC-2190:
--
Comment: was deleted
(was: Yes, I'm very clear about what's supported and it's a really small list,
and the Windows policy is exactly that.
For the record, Server 2008 is not EOL. It's fully supported in Azure, which
means there's nothing about it that's not supported other than the blackmail by
MS to move people to their cloud. As a platform, nothing's really changed for
my projects, it remains supported.
I personally only support the compiler I use, which is 2017 at the moment. As a
project I don't have an opinion other than to say I can't spend any time on
issues on any other compiler, so either somebody else has to or it needs to be
clear that that's all that's supported.
My point re: this change is just that I don't see a huge win or any sort of
"cleanup" gained from ripping the code out and breaking the unsupported
versions. I'm not saying we should support older versions, but that's not the
same as breaking them. But if you feel strongly I'm fine with it.
Re: C++11, I don't know offhand. I have not moved any of my code to any
C++11-only areas but that doesn't mean I couldn't, I would have to review the
compiler history and platforms. I'm very boost-heavy in my code if I need
something newish because I can get that everywhere I need it.)
> deprecated GetVersionEx
> ---
>
> Key: XERCESC-2190
> URL: https://issues.apache.org/jira/browse/XERCESC-2190
> Project: Xerces-C++
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Aleksey Dobrunov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hello.
> *"GetVersionEx* may be altered or unavailable for releases after Windows 8.1.
> Instead, use the [Version Helper
> functions"|https://docs.microsoft.com/windows/desktop/SysInfo/version-helper-apis]
>
> [https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getversionexa]
> .
> {code:java}
> C:\Work\code\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(323):
> warning C4996: 'GetVersionExA': was declared deprecated
> C:\Program Files (x86)\Windows
> Kits\10\include\10.0.18362.0\um\sysinfoapi.h(387): note: see declaration of
> 'GetVersionExA'
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2190) deprecated GetVersionEx
[
https://issues.apache.org/jira/browse/XERCESC-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17073023#comment-17073023
]
Scott Cantor commented on XERCESC-2190:
---
Yes, I'm very clear about what's supported and it's a really small list, and
the Windows policy is exactly that.
For the record, Server 2008 is not EOL. It's fully supported in Azure, which
means there's nothing about it that's not supported other than the blackmail by
MS to move people to their cloud. As a platform, nothing's really changed for
my projects, it remains supported.
I personally only support the compiler I use, which is 2017 at the moment. As a
project I don't have an opinion other than to say I can't spend any time on
issues on any other compiler, so either somebody else has to or it needs to be
clear that that's all that's supported.
My point re: this change is just that I don't see a huge win or any sort of
"cleanup" gained from ripping the code out and breaking the unsupported
versions. I'm not saying we should support older versions, but that's not the
same as breaking them. But if you feel strongly I'm fine with it.
Re: C++11, I don't know offhand. I have not moved any of my code to any
C++11-only areas but that doesn't mean I couldn't, I would have to review the
compiler history and platforms. I'm very boost-heavy in my code if I need
something newish because I can get that everywhere I need it.
> deprecated GetVersionEx
> ---
>
> Key: XERCESC-2190
> URL: https://issues.apache.org/jira/browse/XERCESC-2190
> Project: Xerces-C++
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Aleksey Dobrunov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hello.
> *"GetVersionEx* may be altered or unavailable for releases after Windows 8.1.
> Instead, use the [Version Helper
> functions"|https://docs.microsoft.com/windows/desktop/SysInfo/version-helper-apis]
>
> [https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getversionexa]
> .
> {code:java}
> C:\Work\code\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(323):
> warning C4996: 'GetVersionExA': was declared deprecated
> C:\Program Files (x86)\Windows
> Kits\10\include\10.0.18362.0\um\sysinfoapi.h(387): note: see declaration of
> 'GetVersionExA'
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-1963) Custom HTTP headers missing with CURL NetAccessor
[ https://issues.apache.org/jira/browse/XERCESC-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor updated XERCESC-1963: -- Affects Version/s: 3.0.0 3.0.1 3.0.2 3.1.0 3.1.2 3.2.0 3.1.3 3.1.4 3.2.1 3.2.2 > Custom HTTP headers missing with CURL NetAccessor > -- > > Key: XERCESC-1963 > URL: https://issues.apache.org/jira/browse/XERCESC-1963 > Project: Xerces-C++ > Issue Type: Bug > Components: Utilities >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 > Environment: Xerces-c 3.1.1 > curl_version: libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3 > Mac OS X 10.6.7, i686-apple-darwin10-g++-4.2.1 >Reporter: Eric Swalens >Priority: Minor > Labels: patch > Attachments: CurlURLInputStream-headers-0.1.patch > > > It seems that the custom headers set using XMLNetHTTPInfo are missing from > the actual HTTP request when the CURLNetAccessor is used. The > SocketNetAccessor does not show this problem. > The headerList in the CurlURLInputStream constructor is correctly built but > from what I understand of the CURL documentation the list cannot be freed > until the GET request has been made. Currently the list feed right after > setting the CURLOPT_HTTPHEADER. Delaying the call curl_slist_free_all to the > destructor solves the issue (patch attached). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2190) deprecated GetVersionEx
[
https://issues.apache.org/jira/browse/XERCESC-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17073003#comment-17073003
]
Roger Leigh commented on XERCESC-2190:
--
I think that as a project we should have a clearly supported list of platforms
and compilers which we target, and be very clear about what isn't supported.
When it comes to Windows, I'd personally cut it off when Microsoft stop
supporting it completely. I've generally used their support page for this.
For example:
https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet By
this page, the final Windows 7 release went out of support in January, and also
so did the server version Windows 2008R2. This leaves us with Windows 8.1 and
10 to support.
On top of this, there are the corresponding Visual Studio versions which
support these releases. For these two major versions, that includes VS2013,
VS2015, VS2017 and VS2019. In other projects, I target a maximum of three
Visual Studio releases simply due to the logistics of testing and supporting
several versions. For Xerces-C, I'd suggest that as the maximum due to the
manpower available. That would give use a VS2015 baseline.
For 3.3, if that sounds reasonable, I'd like to make that official. Similarly,
making C++11 the minimum on all platforms would be something to consider, given
that at this point it's available almost universally.
> deprecated GetVersionEx
> ---
>
> Key: XERCESC-2190
> URL: https://issues.apache.org/jira/browse/XERCESC-2190
> Project: Xerces-C++
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Aleksey Dobrunov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hello.
> *"GetVersionEx* may be altered or unavailable for releases after Windows 8.1.
> Instead, use the [Version Helper
> functions"|https://docs.microsoft.com/windows/desktop/SysInfo/version-helper-apis]
>
> [https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getversionexa]
> .
> {code:java}
> C:\Work\code\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(323):
> warning C4996: 'GetVersionExA': was declared deprecated
> C:\Program Files (x86)\Windows
> Kits\10\include\10.0.18362.0\um\sysinfoapi.h(387): note: see declaration of
> 'GetVersionExA'
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Assigned] (XERCESC-1963) Custom HTTP headers missing with CURL NetAccessor
[ https://issues.apache.org/jira/browse/XERCESC-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor reassigned XERCESC-1963: - Assignee: Scott Cantor > Custom HTTP headers missing with CURL NetAccessor > -- > > Key: XERCESC-1963 > URL: https://issues.apache.org/jira/browse/XERCESC-1963 > Project: Xerces-C++ > Issue Type: Bug > Components: Utilities >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 > Environment: Xerces-c 3.1.1 > curl_version: libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3 > Mac OS X 10.6.7, i686-apple-darwin10-g++-4.2.1 >Reporter: Eric Swalens >Assignee: Scott Cantor >Priority: Minor > Labels: patch > Fix For: 3.2.3 > > Attachments: CurlURLInputStream-headers-0.1.patch > > > It seems that the custom headers set using XMLNetHTTPInfo are missing from > the actual HTTP request when the CURLNetAccessor is used. The > SocketNetAccessor does not show this problem. > The headerList in the CurlURLInputStream constructor is correctly built but > from what I understand of the CURL documentation the list cannot be freed > until the GET request has been made. Currently the list feed right after > setting the CURLOPT_HTTPHEADER. Delaying the call curl_slist_free_all to the > destructor solves the issue (patch attached). -- 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-1963) Custom HTTP headers missing with CURL NetAccessor
[ https://issues.apache.org/jira/browse/XERCESC-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor updated XERCESC-1963: -- Fix Version/s: 3.2.3 > Custom HTTP headers missing with CURL NetAccessor > -- > > Key: XERCESC-1963 > URL: https://issues.apache.org/jira/browse/XERCESC-1963 > Project: Xerces-C++ > Issue Type: Bug > Components: Utilities >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 > Environment: Xerces-c 3.1.1 > curl_version: libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3 > Mac OS X 10.6.7, i686-apple-darwin10-g++-4.2.1 >Reporter: Eric Swalens >Priority: Minor > Labels: patch > Fix For: 3.2.3 > > Attachments: CurlURLInputStream-headers-0.1.patch > > > It seems that the custom headers set using XMLNetHTTPInfo are missing from > the actual HTTP request when the CURLNetAccessor is used. The > SocketNetAccessor does not show this problem. > The headerList in the CurlURLInputStream constructor is correctly built but > from what I understand of the CURL documentation the list cannot be freed > until the GET request has been made. Currently the list feed right after > setting the CURLOPT_HTTPHEADER. Delaying the call curl_slist_free_all to the > destructor solves the issue (patch attached). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2176) Incorrect symbolic links created for Linux static library and MacOS static and shared libraries
[
https://issues.apache.org/jira/browse/XERCESC-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17072992#comment-17072992
]
Scott Cantor commented on XERCESC-2176:
---
It's not an issue for me, I'm just trying to get people to stop banging their
heads against it.
FWIW, I'm probably going to just shoot for a 3.2.3 patch very shortly with the
small set of current changes. I don't need any CMake fixes for that but
obviously if you want to do more you can.
> Incorrect symbolic links created for Linux static library and MacOS static
> and shared libraries
> ---
>
> Key: XERCESC-2176
> URL: https://issues.apache.org/jira/browse/XERCESC-2176
> Project: Xerces-C++
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.2.0, 3.2.1, 3.2.2
> Environment: Linux, MacOS
>Reporter: Brent Davis
>Assignee: Roger Leigh
>Priority: Minor
> Fix For: 3.2.3
>
>
> We build Xerces-C++ for both the Linux and MacOS platforms, with both static
> and shared libraries. There are arguably some dubiously named symbolic links
> created by src/CMakeLists.txt. The symlinks are always named
> 'libxerces-c.so' regardless or library type, or use of the .dylib extension
> on MacOS.
> ||Platform||Library Type||Symbolic Link||Comment||
> |{color:#de350b}Linux{color}|{color:#de350b}static{color}|{color:#de350b}libxerces-c.so
> -> libxerces-c-3.2.a{color}|{color:#de350b}symbolic link should either be
> libxerces-c.a or not created{color}|
> |{color:#00875a}
> {color}|{color:#00875a}shared{color}|{color:#00875a}libxerces-c.so ->
> libxerces-c-3.2.so{color}|{color:#00875a}good{color}|
> |{color:#de350b}MacOS{color}|{color:#de350b}static{color}|{color:#de350b}libxerces-c.so
> -> libxerces-c-3.2.a{color}|{color:#de350b}symbolic link should either be
> libxerces-c.a or not created{color}|
> |{color:#de350b}
> {color}|{color:#de350b}shared{color}|{color:#de350b}libxerces-c.so ->
> libxerces-c-3.2.dylib{color}|{color:#de350b}symbolic link should best be
> named libxerces-c.dylib{color}|
> Curiously, the Microsoft _vcpkg_ folks just recently ran into the Linux
> static library portion of this issue and elected to not create the symlink in
> that case. See [[xerces-c] produces strange files in
> installed/x64-linux/lib|[https://github.com/microsoft/vcpkg/issues/7490]].
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2190) deprecated GetVersionEx
[
https://issues.apache.org/jira/browse/XERCESC-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17072989#comment-17072989
]
Scott Cantor commented on XERCESC-2190:
---
I definitely agree *for my purposes* but my point was that I tend not to
introduce changes that don't actually fix an issue *and* end up changing where
the code will run if I don't have a reason to do it.
In this case, I would say to leave it and if/when GetVersionEx does disappear
and start causing real problems on supported platforms, we can have a record
that it's safe to just yank.
So I think we have what we need but no reason to do anything at this time.
But as I say, that's just my perspective on how to deal with these kinds of
issues.
> deprecated GetVersionEx
> ---
>
> Key: XERCESC-2190
> URL: https://issues.apache.org/jira/browse/XERCESC-2190
> Project: Xerces-C++
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Aleksey Dobrunov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hello.
> *"GetVersionEx* may be altered or unavailable for releases after Windows 8.1.
> Instead, use the [Version Helper
> functions"|https://docs.microsoft.com/windows/desktop/SysInfo/version-helper-apis]
>
> [https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getversionexa]
> .
> {code:java}
> C:\Work\code\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(323):
> warning C4996: 'GetVersionExA': was declared deprecated
> C:\Program Files (x86)\Windows
> Kits\10\include\10.0.18362.0\um\sysinfoapi.h(387): note: see declaration of
> 'GetVersionExA'
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2176) Incorrect symbolic links created for Linux static library and MacOS static and shared libraries
[
https://issues.apache.org/jira/browse/XERCESC-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17072988#comment-17072988
]
Roger Leigh commented on XERCESC-2176:
--
Sorry I've not had time to devote to this yet, I've had a very busy couple of
months.
> Incorrect symbolic links created for Linux static library and MacOS static
> and shared libraries
> ---
>
> Key: XERCESC-2176
> URL: https://issues.apache.org/jira/browse/XERCESC-2176
> Project: Xerces-C++
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.2.0, 3.2.1, 3.2.2
> Environment: Linux, MacOS
>Reporter: Brent Davis
>Assignee: Roger Leigh
>Priority: Minor
> Fix For: 3.2.3
>
>
> We build Xerces-C++ for both the Linux and MacOS platforms, with both static
> and shared libraries. There are arguably some dubiously named symbolic links
> created by src/CMakeLists.txt. The symlinks are always named
> 'libxerces-c.so' regardless or library type, or use of the .dylib extension
> on MacOS.
> ||Platform||Library Type||Symbolic Link||Comment||
> |{color:#de350b}Linux{color}|{color:#de350b}static{color}|{color:#de350b}libxerces-c.so
> -> libxerces-c-3.2.a{color}|{color:#de350b}symbolic link should either be
> libxerces-c.a or not created{color}|
> |{color:#00875a}
> {color}|{color:#00875a}shared{color}|{color:#00875a}libxerces-c.so ->
> libxerces-c-3.2.so{color}|{color:#00875a}good{color}|
> |{color:#de350b}MacOS{color}|{color:#de350b}static{color}|{color:#de350b}libxerces-c.so
> -> libxerces-c-3.2.a{color}|{color:#de350b}symbolic link should either be
> libxerces-c.a or not created{color}|
> |{color:#de350b}
> {color}|{color:#de350b}shared{color}|{color:#de350b}libxerces-c.so ->
> libxerces-c-3.2.dylib{color}|{color:#de350b}symbolic link should best be
> named libxerces-c.dylib{color}|
> Curiously, the Microsoft _vcpkg_ folks just recently ran into the Linux
> static library portion of this issue and elected to not create the symlink in
> that case. See [[xerces-c] produces strange files in
> installed/x64-linux/lib|[https://github.com/microsoft/vcpkg/issues/7490]].
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2190) deprecated GetVersionEx
[
https://issues.apache.org/jira/browse/XERCESC-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17072987#comment-17072987
]
Roger Leigh commented on XERCESC-2190:
--
I checked both call sites.
WindowsFileMgr.cpp: Used to check if on NT or not. Can be dropped entirely (I
doubt anyone cares about Windows 9x at this point)
Win32TransService: Used to check if on XP or later. Can be dropped entirely
(even XP is obsolete and unsupported at this point)
So both should be completely safe to drop. They are only needed for Win9x and
Win2000 respectively.
> deprecated GetVersionEx
> ---
>
> Key: XERCESC-2190
> URL: https://issues.apache.org/jira/browse/XERCESC-2190
> Project: Xerces-C++
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Aleksey Dobrunov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hello.
> *"GetVersionEx* may be altered or unavailable for releases after Windows 8.1.
> Instead, use the [Version Helper
> functions"|https://docs.microsoft.com/windows/desktop/SysInfo/version-helper-apis]
>
> [https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getversionexa]
> .
> {code:java}
> C:\Work\code\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(323):
> warning C4996: 'GetVersionExA': was declared deprecated
> C:\Program Files (x86)\Windows
> Kits\10\include\10.0.18362.0\um\sysinfoapi.h(387): note: see declaration of
> 'GetVersionExA'
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2138) Xerces-C++ should use C++98 features and remove pre-Standard workarounds
[ https://issues.apache.org/jira/browse/XERCESC-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor updated XERCESC-2138: -- Affects Version/s: (was: 3.2.0) > Xerces-C++ should use C++98 features and remove pre-Standard workarounds > > > Key: XERCESC-2138 > URL: https://issues.apache.org/jira/browse/XERCESC-2138 > Project: Xerces-C++ > Issue Type: Improvement > Components: Build >Reporter: Johnny Willemsen >Assignee: Roger Leigh >Priority: Trivial > Fix For: 3.3.0 > > Attachments: 0001-Make-XSConstants-a-namespace.patch, > 0002-Drop-XERCES_HAS_CPP_NAMESPACE-check.patch, > 0003-Drop-XERCES_STD_NAMESPACE-check.patch, > 0004-Drop-XERCES_NO_NATIVE_BOOL-check.patch, > 0005-Drop-XERCES_NEW_IOSTREAMS-check.patch, > 0006-Use-cstdlib-in-place-of-stdlib.h.patch, > 0007-Use-cstdio-in-place-of-stdio.h.patch, > 0008-Use-cstring-in-place-of-string.h.patch, > 0009-Remove-use-of-strings.h.patch, > 0010-Use-std-in-place-of-XERCES_STD_QUALIFIER.patch, > 0011-Drop-const-workarounds.patch, 0012-Drop-inline-workarounds.patch, > 0013-Drop-unused-volatile-workarounds.patch, > 0014-Replace-XERCES_CPP_NAMESPACE-macros-with-real-namesp.patch > > > When compiling xercesc-3.2.0 with mingw-64 gcc 4.9.3 on Windows we get a lot > of warnings, for example: > class xercesc_3_2::XSConstants' only defines private constructors and has no > friends > In file included from > C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/src/xercesc/framework/psvi/XSObject.hpp:26:0, > Gandalf_win10_x86_64_01(administrator@172.16.2.213) > [pkg_xercesc:windows-pkg-xercesc] from > C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/src/xercesc/framework/psvi/XSTypeDefinition.hpp:25, > Gandalf_win10_x86_64_01(administrator@172.16.2.213) > [pkg_xercesc:windows-pkg-xercesc] from > C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/src/xercesc/framework/psvi/XSSimpleTypeDefinition.hpp:25, > Gandalf_win10_x86_64_01(administrator@172.16.2.213) > [pkg_xercesc:windows-pkg-xercesc] from > C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/src/xercesc/validators/datatype/DatatypeValidator.hpp:32, > Gandalf_win10_x86_64_01(administrator@172.16.2.213) > [pkg_xercesc:windows-pkg-xercesc] from > C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/src/xercesc/framework/XMLAttr.hpp:28, > Gandalf_win10_x86_64_01(administrator@172.16.2.213) > [pkg_xercesc:windows-pkg-xercesc] from > C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/src/xercesc/framework/XMLValidator.hpp:25, > Gandalf_win10_x86_64_01(administrator@172.16.2.213) > [pkg_xercesc:windows-pkg-xercesc] from > C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/src/xercesc/sax2/SAX2XMLReader.hpp:27, > Gandalf_win10_x86_64_01(administrator@172.16.2.213) > [pkg_xercesc:windows-pkg-xercesc] from > C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/samples/src/SAX2Print/SAX2Print.cpp:28: > Gandalf_win10_x86_64_01(administrator@172.16.2.213) > [pkg_xercesc:windows-pkg-xercesc] > C:/cygwin64/home/administrator/build-ad87109bfff0765f4dd8cf4943b04d16a4070fea/xerces-c-3.2.0/src/xercesc/framework/psvi/XSConstants.hpp:56:24: > warning: 'class xercesc_3_2::XSConstants' only defines private constructors > and has no friends [-Wctor-dtor-privacy] > Gandalf_win10_x86_64_01(administrator@172.16.2.213) > [pkg_xercesc:windows-pkg-xercesc] class XMLPARSER_EXPORT XSConstants > Gandalf_win10_x86_64_01(administrator@172.16.2.213) > [pkg_xercesc:windows-pkg-xercesc] ^ -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2141) Enable C++11/14 with autoconf build
[ https://issues.apache.org/jira/browse/XERCESC-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor updated XERCESC-2141: -- Fix Version/s: 3.3.0 > Enable C++11/14 with autoconf build > --- > > Key: XERCESC-2141 > URL: https://issues.apache.org/jira/browse/XERCESC-2141 > Project: Xerces-C++ > Issue Type: Improvement > Components: Build >Reporter: Roger Leigh >Priority: Major > Labels: autoconf, build, c++11, c++14 > Fix For: 3.3.0 > > Attachments: 0001-autoconf-Enable-C-14-or-C-11-when-available.patch > > > The CMake build will try to put the compiler in C++14 mode, falling back to > C++11 then C++98. The autoconf build doesn't do this, and the attached patch > makes the behaviour match so both build systems will use the same fallbacks. > Current compilers default to C++14. Very old compilers have no support for > C++11 or C++14. But compilers in between support it, but not by default. > This adds the feature tests to check for such support and enable it when > available. > The CMake C++ standard support is user-configurable by setting the > CMAKE_CXX_STANDARD setting. Autoconf doesn't provide any way to do this, so > the feature enabling isn't explicitly overridable. I'm not sure if that's > too problematic. The main compatibility concern might be if this causes an > ABI break with use of C++11/14 library features like the new string type. > However, we aren't making use of any of these features. The main change > would be the XMLCh type switch from uint16_t to char16_t. I'm not sure what > the Xerces policy for such changes has been in the past. Any thoughts? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2141) Enable C++11/14 with autoconf build
[ https://issues.apache.org/jira/browse/XERCESC-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17072983#comment-17072983 ] Scott Cantor commented on XERCESC-2141: --- I targeted this for 3.3 so if there ever is one we can just do it then and not worry about any changes from it. > Enable C++11/14 with autoconf build > --- > > Key: XERCESC-2141 > URL: https://issues.apache.org/jira/browse/XERCESC-2141 > Project: Xerces-C++ > Issue Type: Improvement > Components: Build >Reporter: Roger Leigh >Priority: Major > Labels: autoconf, build, c++11, c++14 > Fix For: 3.3.0 > > Attachments: 0001-autoconf-Enable-C-14-or-C-11-when-available.patch > > > The CMake build will try to put the compiler in C++14 mode, falling back to > C++11 then C++98. The autoconf build doesn't do this, and the attached patch > makes the behaviour match so both build systems will use the same fallbacks. > Current compilers default to C++14. Very old compilers have no support for > C++11 or C++14. But compilers in between support it, but not by default. > This adds the feature tests to check for such support and enable it when > available. > The CMake C++ standard support is user-configurable by setting the > CMAKE_CXX_STANDARD setting. Autoconf doesn't provide any way to do this, so > the feature enabling isn't explicitly overridable. I'm not sure if that's > too problematic. The main compatibility concern might be if this causes an > ABI break with use of C++11/14 library features like the new string type. > However, we aren't making use of any of these features. The main change > would be the XMLCh type switch from uint16_t to char16_t. I'm not sure what > the Xerces policy for such changes has been in the past. Any thoughts? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2160) Postpone freeing the memory being used by CURL
[ https://issues.apache.org/jira/browse/XERCESC-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor updated XERCESC-2160: -- Affects Version/s: (was: 3.2.3) > Postpone freeing the memory being used by CURL > -- > > Key: XERCESC-2160 > URL: https://issues.apache.org/jira/browse/XERCESC-2160 > Project: Xerces-C++ > Issue Type: Bug > Components: Utilities >Affects Versions: 3.2.0, 3.2.1, 3.2.2 > Environment: Ubuntu 16.04 LTS >Reporter: Zane U. Ji >Assignee: Scott Cantor >Priority: Major > Fix For: 3.2.3 > > Attachments: 0001-Postpone-freeing-the-memory-being-used-by-CURL.patch > > > Some sites require a valid User-Agent HTTP header. However, xerces-c crashes > when a HTTP header is set. The patch fixes the problem. -- 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-2160) Postpone freeing the memory being used by CURL
[ https://issues.apache.org/jira/browse/XERCESC-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17072976#comment-17072976 ] Scott Cantor commented on XERCESC-2160: --- Per recent discussion it seems that people are comfortable with treating truly internal classes as off-limits and not subject to ABI policy as long as nothing should be embedding them, and this fits that criteria, so I will see about applying this to both branches. > Postpone freeing the memory being used by CURL > -- > > Key: XERCESC-2160 > URL: https://issues.apache.org/jira/browse/XERCESC-2160 > Project: Xerces-C++ > Issue Type: Bug > Components: Utilities >Affects Versions: 3.2.0, 3.2.1, 3.2.2, 3.2.3 > Environment: Ubuntu 16.04 LTS >Reporter: Zane U. Ji >Assignee: Scott Cantor >Priority: Major > Fix For: 3.3.0 > > Attachments: 0001-Postpone-freeing-the-memory-being-used-by-CURL.patch > > > Some sites require a valid User-Agent HTTP header. However, xerces-c crashes > when a HTTP header is set. The patch fixes the problem. -- 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-2160) Postpone freeing the memory being used by CURL
[ https://issues.apache.org/jira/browse/XERCESC-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor updated XERCESC-2160: -- Fix Version/s: (was: 3.3.0) 3.2.3 > Postpone freeing the memory being used by CURL > -- > > Key: XERCESC-2160 > URL: https://issues.apache.org/jira/browse/XERCESC-2160 > Project: Xerces-C++ > Issue Type: Bug > Components: Utilities >Affects Versions: 3.2.0, 3.2.1, 3.2.2, 3.2.3 > Environment: Ubuntu 16.04 LTS >Reporter: Zane U. Ji >Assignee: Scott Cantor >Priority: Major > Fix For: 3.2.3 > > Attachments: 0001-Postpone-freeing-the-memory-being-used-by-CURL.patch > > > Some sites require a valid User-Agent HTTP header. However, xerces-c crashes > when a HTTP header is set. The patch fixes the problem. -- 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-2167) Do not set SONAME when building shared libs
[
https://issues.apache.org/jira/browse/XERCESC-2167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17072969#comment-17072969
]
Scott Cantor commented on XERCESC-2167:
---
Strongly suggest you stick with the autoconf build for a non-Windows use case.
> Do not set SONAME when building shared libs
> ---
>
> Key: XERCESC-2167
> URL: https://issues.apache.org/jira/browse/XERCESC-2167
> Project: Xerces-C++
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.2.0, 3.2.1, 3.2.2
>Reporter: Jeroen
>Assignee: Roger Leigh
>Priority: Major
> Fix For: 3.2.3
>
>
>
> When building a static library (i.e. building with {{cmake
> -DBUILD_SHARED_LIBS=OFF}}, we should not set a SONAME or rename the library
> file. A static library should just be named libxerces-c.a and not
> libxerces-c-3.2.a (otherwise it won't link with -lxerces-c).
> Here is a very simple example patch:
> [https://patch-diff.githubusercontent.com/raw/jeroen/xerces-c/pull/1.patch]
>
> Thank you!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2176) Incorrect symbolic links created for Linux static library and MacOS static and shared libraries
[
https://issues.apache.org/jira/browse/XERCESC-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17072968#comment-17072968
]
Scott Cantor commented on XERCESC-2176:
---
Strongly suggest you use the autoconf build for any non-Windows project. If
that's also broken I can look at it.
> Incorrect symbolic links created for Linux static library and MacOS static
> and shared libraries
> ---
>
> Key: XERCESC-2176
> URL: https://issues.apache.org/jira/browse/XERCESC-2176
> Project: Xerces-C++
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.2.0, 3.2.1, 3.2.2
> Environment: Linux, MacOS
>Reporter: Brent Davis
>Assignee: Roger Leigh
>Priority: Minor
> Fix For: 3.2.3
>
>
> We build Xerces-C++ for both the Linux and MacOS platforms, with both static
> and shared libraries. There are arguably some dubiously named symbolic links
> created by src/CMakeLists.txt. The symlinks are always named
> 'libxerces-c.so' regardless or library type, or use of the .dylib extension
> on MacOS.
> ||Platform||Library Type||Symbolic Link||Comment||
> |{color:#de350b}Linux{color}|{color:#de350b}static{color}|{color:#de350b}libxerces-c.so
> -> libxerces-c-3.2.a{color}|{color:#de350b}symbolic link should either be
> libxerces-c.a or not created{color}|
> |{color:#00875a}
> {color}|{color:#00875a}shared{color}|{color:#00875a}libxerces-c.so ->
> libxerces-c-3.2.so{color}|{color:#00875a}good{color}|
> |{color:#de350b}MacOS{color}|{color:#de350b}static{color}|{color:#de350b}libxerces-c.so
> -> libxerces-c-3.2.a{color}|{color:#de350b}symbolic link should either be
> libxerces-c.a or not created{color}|
> |{color:#de350b}
> {color}|{color:#de350b}shared{color}|{color:#de350b}libxerces-c.so ->
> libxerces-c-3.2.dylib{color}|{color:#de350b}symbolic link should best be
> named libxerces-c.dylib{color}|
> Curiously, the Microsoft _vcpkg_ folks just recently ran into the Linux
> static library portion of this issue and elected to not create the symlink in
> that case. See [[xerces-c] produces strange files in
> installed/x64-linux/lib|[https://github.com/microsoft/vcpkg/issues/7490]].
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2182) Obsolete default namespace declaration when create element with default namespace URI
[ https://issues.apache.org/jira/browse/XERCESC-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17072963#comment-17072963 ] Scott Cantor commented on XERCESC-2182: --- I think I have some idea what you mean, but an explicit example so I can verify my understanding would help a lot. > Obsolete default namespace declaration when create element with default > namespace URI > -- > > Key: XERCESC-2182 > URL: https://issues.apache.org/jira/browse/XERCESC-2182 > Project: Xerces-C++ > Issue Type: Bug > Components: DOM >Affects Versions: 3.2.2 >Reporter: Peter Somora >Priority: Major > Attachments: DOMLSSerializerImpl.cpp > > > When qualified element with *default* *namespace URI* is created then xerces > adds (obsolete) default namespace declaration to it. > It looks like bug in `dom\impl\DOMLSSerializerImpl.cpp: line 891` > namespaceMap->put((void*)attribute->getLocalName(),(XMLCh*)attribute->getNodeValue()); > should be: > namespaceMap->put((void*)nsPrefix,(XMLCh*)attribute->getNodeValue()); -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Assigned] (XERCESC-2185) Janitor.hpp fails to compile on Solaris with Solaris Studio 12.2 and 12.4
[ https://issues.apache.org/jira/browse/XERCESC-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor reassigned XERCESC-2185: - Assignee: Scott Cantor > Janitor.hpp fails to compile on Solaris with Solaris Studio 12.2 and 12.4 > - > > Key: XERCESC-2185 > URL: https://issues.apache.org/jira/browse/XERCESC-2185 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.2 > Environment: SunOS 5.10 Generic_147440-12 sun4v sparc > sun4v > CC: Sun C++ 5.11 SunOS_sparc 2010/08/13 >Reporter: Alexey Roytman >Assignee: Scott Cantor >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > When compiling xerces-c 3.2.2 on Solaris SPARC with Solaris Studio 12.2 and > 12.4, the configuration stage passes, but the build fails on these 2 lines in > Janitor.hpp: > 158 XERCES_TEMPLATE_EXTERN template class XMLUTIL_EXPORT > ArrayJanitor; > 159 XERCES_TEMPLATE_EXTERN template class XMLUTIL_EXPORT ArrayJanitor; > The error messages are: > "./xercesc/util/Janitor.hpp", line 158: Error: A declaration does not specify > a tag or an identifier. > "./xercesc/util/Janitor.hpp", line 158: Error: Use ";" to terminate > declarations. > "./xercesc/util/Janitor.hpp", line 159: Error: A declaration does not specify > a tag or an identifier. > "./xercesc/util/Janitor.hpp", line 159: Error: Use ";" to terminate > declarations. > When I comment out these 2 lines, the builds succeeds. I did not run the > tests... > The xerces-c 3.2.1 was built on the same environment successfully. -- 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-2185) Janitor.hpp fails to compile on Solaris with Solaris Studio 12.2 and 12.4
[ https://issues.apache.org/jira/browse/XERCESC-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor updated XERCESC-2185: -- Fix Version/s: 3.2.3 > Janitor.hpp fails to compile on Solaris with Solaris Studio 12.2 and 12.4 > - > > Key: XERCESC-2185 > URL: https://issues.apache.org/jira/browse/XERCESC-2185 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.2 > Environment: SunOS 5.10 Generic_147440-12 sun4v sparc > sun4v > CC: Sun C++ 5.11 SunOS_sparc 2010/08/13 >Reporter: Alexey Roytman >Assignee: Scott Cantor >Priority: Major > Fix For: 3.2.3 > > Time Spent: 10m > Remaining Estimate: 0h > > When compiling xerces-c 3.2.2 on Solaris SPARC with Solaris Studio 12.2 and > 12.4, the configuration stage passes, but the build fails on these 2 lines in > Janitor.hpp: > 158 XERCES_TEMPLATE_EXTERN template class XMLUTIL_EXPORT > ArrayJanitor; > 159 XERCES_TEMPLATE_EXTERN template class XMLUTIL_EXPORT ArrayJanitor; > The error messages are: > "./xercesc/util/Janitor.hpp", line 158: Error: A declaration does not specify > a tag or an identifier. > "./xercesc/util/Janitor.hpp", line 158: Error: Use ";" to terminate > declarations. > "./xercesc/util/Janitor.hpp", line 159: Error: A declaration does not specify > a tag or an identifier. > "./xercesc/util/Janitor.hpp", line 159: Error: Use ";" to terminate > declarations. > When I comment out these 2 lines, the builds succeeds. I did not run the > tests... > The xerces-c 3.2.1 was built on the same environment successfully. -- 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-2185) Janitor.hpp fails to compile on Solaris with Solaris Studio 12.2 and 12.4
[ https://issues.apache.org/jira/browse/XERCESC-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17072958#comment-17072958 ] Scott Cantor commented on XERCESC-2185: --- Fixed per XERCESC-2187. > Janitor.hpp fails to compile on Solaris with Solaris Studio 12.2 and 12.4 > - > > Key: XERCESC-2185 > URL: https://issues.apache.org/jira/browse/XERCESC-2185 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.2 > Environment: SunOS 5.10 Generic_147440-12 sun4v sparc > sun4v > CC: Sun C++ 5.11 SunOS_sparc 2010/08/13 >Reporter: Alexey Roytman >Assignee: Scott Cantor >Priority: Major > Fix For: 3.2.3 > > Time Spent: 10m > Remaining Estimate: 0h > > When compiling xerces-c 3.2.2 on Solaris SPARC with Solaris Studio 12.2 and > 12.4, the configuration stage passes, but the build fails on these 2 lines in > Janitor.hpp: > 158 XERCES_TEMPLATE_EXTERN template class XMLUTIL_EXPORT > ArrayJanitor; > 159 XERCES_TEMPLATE_EXTERN template class XMLUTIL_EXPORT ArrayJanitor; > The error messages are: > "./xercesc/util/Janitor.hpp", line 158: Error: A declaration does not specify > a tag or an identifier. > "./xercesc/util/Janitor.hpp", line 158: Error: Use ";" to terminate > declarations. > "./xercesc/util/Janitor.hpp", line 159: Error: A declaration does not specify > a tag or an identifier. > "./xercesc/util/Janitor.hpp", line 159: Error: Use ";" to terminate > declarations. > When I comment out these 2 lines, the builds succeeds. I did not run the > tests... > The xerces-c 3.2.1 was built on the same environment successfully. -- 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] [Closed] (XERCESC-2185) Janitor.hpp fails to compile on Solaris with Solaris Studio 12.2 and 12.4
[ https://issues.apache.org/jira/browse/XERCESC-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor closed XERCESC-2185. - > Janitor.hpp fails to compile on Solaris with Solaris Studio 12.2 and 12.4 > - > > Key: XERCESC-2185 > URL: https://issues.apache.org/jira/browse/XERCESC-2185 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.2 > Environment: SunOS 5.10 Generic_147440-12 sun4v sparc > sun4v > CC: Sun C++ 5.11 SunOS_sparc 2010/08/13 >Reporter: Alexey Roytman >Assignee: Scott Cantor >Priority: Major > Fix For: 3.2.3 > > Time Spent: 10m > Remaining Estimate: 0h > > When compiling xerces-c 3.2.2 on Solaris SPARC with Solaris Studio 12.2 and > 12.4, the configuration stage passes, but the build fails on these 2 lines in > Janitor.hpp: > 158 XERCES_TEMPLATE_EXTERN template class XMLUTIL_EXPORT > ArrayJanitor; > 159 XERCES_TEMPLATE_EXTERN template class XMLUTIL_EXPORT ArrayJanitor; > The error messages are: > "./xercesc/util/Janitor.hpp", line 158: Error: A declaration does not specify > a tag or an identifier. > "./xercesc/util/Janitor.hpp", line 158: Error: Use ";" to terminate > declarations. > "./xercesc/util/Janitor.hpp", line 159: Error: A declaration does not specify > a tag or an identifier. > "./xercesc/util/Janitor.hpp", line 159: Error: Use ";" to terminate > declarations. > When I comment out these 2 lines, the builds succeeds. I did not run the > tests... > The xerces-c 3.2.1 was built on the same environment successfully. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2185) Janitor.hpp fails to compile on Solaris with Solaris Studio 12.2 and 12.4
[ https://issues.apache.org/jira/browse/XERCESC-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor resolved XERCESC-2185. --- Resolution: Fixed > Janitor.hpp fails to compile on Solaris with Solaris Studio 12.2 and 12.4 > - > > Key: XERCESC-2185 > URL: https://issues.apache.org/jira/browse/XERCESC-2185 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.2 > Environment: SunOS 5.10 Generic_147440-12 sun4v sparc > sun4v > CC: Sun C++ 5.11 SunOS_sparc 2010/08/13 >Reporter: Alexey Roytman >Assignee: Scott Cantor >Priority: Major > Fix For: 3.2.3 > > Time Spent: 10m > Remaining Estimate: 0h > > When compiling xerces-c 3.2.2 on Solaris SPARC with Solaris Studio 12.2 and > 12.4, the configuration stage passes, but the build fails on these 2 lines in > Janitor.hpp: > 158 XERCES_TEMPLATE_EXTERN template class XMLUTIL_EXPORT > ArrayJanitor; > 159 XERCES_TEMPLATE_EXTERN template class XMLUTIL_EXPORT ArrayJanitor; > The error messages are: > "./xercesc/util/Janitor.hpp", line 158: Error: A declaration does not specify > a tag or an identifier. > "./xercesc/util/Janitor.hpp", line 158: Error: Use ";" to terminate > declarations. > "./xercesc/util/Janitor.hpp", line 159: Error: A declaration does not specify > a tag or an identifier. > "./xercesc/util/Janitor.hpp", line 159: Error: Use ";" to terminate > declarations. > When I comment out these 2 lines, the builds succeeds. I did not run the > tests... > The xerces-c 3.2.1 was built on the same environment successfully. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Assigned] (XERCESC-2186) undef symbols on HPUX for ArrayJanitor
[ https://issues.apache.org/jira/browse/XERCESC-2186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor reassigned XERCESC-2186: - Assignee: Scott Cantor > undef symbols on HPUX for ArrayJanitor > -- > > Key: XERCESC-2186 > URL: https://issues.apache.org/jira/browse/XERCESC-2186 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.2 > Environment: HP-UX B.11.31 U ia64 > aCC: HP C/aC++ B3910B A.06.28 [Nov 21 2013] >Reporter: Alexey Roytman >Assignee: Scott Cantor >Priority: Major > Fix For: 3.2.3 > > > When compiling xerces-c 3.2.2 on HP-UX 11.31 with HP-UX C++ compiler A.06.28, > there are undefined symbols in the shared library: > CXXLD PSVIWriter > fails because of some missing symbols. > nm ./src/.libs/libxerces-c.so | grep ArrayJanitor | c++filt | grep UNDEF > [5645] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::reset(unsigned char*,xercesc_3_2::MemoryManager*) > [13918] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::release() > [10852] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::ArrayJanitor(unsigned char*)(complete) > [4694] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::ArrayJanitor(unsigned char*,xercesc_3_2::MemoryManager*)(complete) > [10308] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::~ArrayJanitor()(complete) > [5344] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::reset(unsigned short*,xercesc_3_2::MemoryManager*) > [13909] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::release() > [10884] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::ArrayJanitor(unsigned short*)(complete) > [12717] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::ArrayJanitor(unsigned short*,xercesc_3_2::MemoryManager*)(complete) > [10227] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::~ArrayJanitor()(complete) > [5251] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::get() const > [8674] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::operator[](unsigned long) const > [3757] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::get() const > [8931] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::operator[](unsigned long) const > > Look at these 2 lines in Janitor.hpp: > 158 XERCES_TEMPLATE_EXTERN template class XMLUTIL_EXPORT > ArrayJanitor; > 159 XERCES_TEMPLATE_EXTERN template class XMLUTIL_EXPORT ArrayJanitor; > When I comment out these 2 lines, the builds succeeds. I did not run the > tests... > The xerces-c 3.2.1 was built on the same environment successfully. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2186) undef symbols on HPUX for ArrayJanitor
[ https://issues.apache.org/jira/browse/XERCESC-2186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor resolved XERCESC-2186. --- Resolution: Fixed > undef symbols on HPUX for ArrayJanitor > -- > > Key: XERCESC-2186 > URL: https://issues.apache.org/jira/browse/XERCESC-2186 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.2 > Environment: HP-UX B.11.31 U ia64 > aCC: HP C/aC++ B3910B A.06.28 [Nov 21 2013] >Reporter: Alexey Roytman >Assignee: Scott Cantor >Priority: Major > Fix For: 3.2.3 > > > When compiling xerces-c 3.2.2 on HP-UX 11.31 with HP-UX C++ compiler A.06.28, > there are undefined symbols in the shared library: > CXXLD PSVIWriter > fails because of some missing symbols. > nm ./src/.libs/libxerces-c.so | grep ArrayJanitor | c++filt | grep UNDEF > [5645] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::reset(unsigned char*,xercesc_3_2::MemoryManager*) > [13918] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::release() > [10852] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::ArrayJanitor(unsigned char*)(complete) > [4694] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::ArrayJanitor(unsigned char*,xercesc_3_2::MemoryManager*)(complete) > [10308] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::~ArrayJanitor()(complete) > [5344] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::reset(unsigned short*,xercesc_3_2::MemoryManager*) > [13909] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::release() > [10884] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::ArrayJanitor(unsigned short*)(complete) > [12717] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::ArrayJanitor(unsigned short*,xercesc_3_2::MemoryManager*)(complete) > [10227] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::~ArrayJanitor()(complete) > [5251] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::get() const > [8674] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::operator[](unsigned long) const > [3757] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::get() const > [8931] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::operator[](unsigned long) const > > Look at these 2 lines in Janitor.hpp: > 158 XERCES_TEMPLATE_EXTERN template class XMLUTIL_EXPORT > ArrayJanitor; > 159 XERCES_TEMPLATE_EXTERN template class XMLUTIL_EXPORT ArrayJanitor; > When I comment out these 2 lines, the builds succeeds. I did not run the > tests... > The xerces-c 3.2.1 was built on the same environment successfully. -- 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-2186) undef symbols on HPUX for ArrayJanitor
[ https://issues.apache.org/jira/browse/XERCESC-2186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17072954#comment-17072954 ] Scott Cantor commented on XERCESC-2186: --- Fixed along with XERCESC-2187. > undef symbols on HPUX for ArrayJanitor > -- > > Key: XERCESC-2186 > URL: https://issues.apache.org/jira/browse/XERCESC-2186 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.2 > Environment: HP-UX B.11.31 U ia64 > aCC: HP C/aC++ B3910B A.06.28 [Nov 21 2013] >Reporter: Alexey Roytman >Assignee: Scott Cantor >Priority: Major > Fix For: 3.2.3 > > > When compiling xerces-c 3.2.2 on HP-UX 11.31 with HP-UX C++ compiler A.06.28, > there are undefined symbols in the shared library: > CXXLD PSVIWriter > fails because of some missing symbols. > nm ./src/.libs/libxerces-c.so | grep ArrayJanitor | c++filt | grep UNDEF > [5645] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::reset(unsigned char*,xercesc_3_2::MemoryManager*) > [13918] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::release() > [10852] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::ArrayJanitor(unsigned char*)(complete) > [4694] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::ArrayJanitor(unsigned char*,xercesc_3_2::MemoryManager*)(complete) > [10308] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::~ArrayJanitor()(complete) > [5344] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::reset(unsigned short*,xercesc_3_2::MemoryManager*) > [13909] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::release() > [10884] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::ArrayJanitor(unsigned short*)(complete) > [12717] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::ArrayJanitor(unsigned short*,xercesc_3_2::MemoryManager*)(complete) > [10227] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::~ArrayJanitor()(complete) > [5251] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::get() const > [8674] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::operator[](unsigned long) const > [3757] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::get() const > [8931] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::operator[](unsigned long) const > > Look at these 2 lines in Janitor.hpp: > 158 XERCES_TEMPLATE_EXTERN template class XMLUTIL_EXPORT > ArrayJanitor; > 159 XERCES_TEMPLATE_EXTERN template class XMLUTIL_EXPORT ArrayJanitor; > When I comment out these 2 lines, the builds succeeds. I did not run the > tests... > The xerces-c 3.2.1 was built on the same environment successfully. -- 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] [Closed] (XERCESC-2186) undef symbols on HPUX for ArrayJanitor
[ https://issues.apache.org/jira/browse/XERCESC-2186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor closed XERCESC-2186. - > undef symbols on HPUX for ArrayJanitor > -- > > Key: XERCESC-2186 > URL: https://issues.apache.org/jira/browse/XERCESC-2186 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.2 > Environment: HP-UX B.11.31 U ia64 > aCC: HP C/aC++ B3910B A.06.28 [Nov 21 2013] >Reporter: Alexey Roytman >Assignee: Scott Cantor >Priority: Major > Fix For: 3.2.3 > > > When compiling xerces-c 3.2.2 on HP-UX 11.31 with HP-UX C++ compiler A.06.28, > there are undefined symbols in the shared library: > CXXLD PSVIWriter > fails because of some missing symbols. > nm ./src/.libs/libxerces-c.so | grep ArrayJanitor | c++filt | grep UNDEF > [5645] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::reset(unsigned char*,xercesc_3_2::MemoryManager*) > [13918] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::release() > [10852] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::ArrayJanitor(unsigned char*)(complete) > [4694] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::ArrayJanitor(unsigned char*,xercesc_3_2::MemoryManager*)(complete) > [10308] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::~ArrayJanitor()(complete) > [5344] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::reset(unsigned short*,xercesc_3_2::MemoryManager*) > [13909] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::release() > [10884] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::ArrayJanitor(unsigned short*)(complete) > [12717] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::ArrayJanitor(unsigned short*,xercesc_3_2::MemoryManager*)(complete) > [10227] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::~ArrayJanitor()(complete) > [5251] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::get() const > [8674] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::operator[](unsigned long) const > [3757] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::get() const > [8931] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::operator[](unsigned long) const > > Look at these 2 lines in Janitor.hpp: > 158 XERCES_TEMPLATE_EXTERN template class XMLUTIL_EXPORT > ArrayJanitor; > 159 XERCES_TEMPLATE_EXTERN template class XMLUTIL_EXPORT ArrayJanitor; > When I comment out these 2 lines, the builds succeeds. I did not run the > tests... > The xerces-c 3.2.1 was built on the same environment successfully. -- 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] [Closed] (XERCESC-2187) DOM tests crash on AIX
[ https://issues.apache.org/jira/browse/XERCESC-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor closed XERCESC-2187. - > DOM tests crash on AIX > -- > > Key: XERCESC-2187 > URL: https://issues.apache.org/jira/browse/XERCESC-2187 > Project: Xerces-C++ > Issue Type: Bug > Components: DOM >Affects Versions: 3.2.1, 3.2.2 > Environment: $ cc_r -qVersion > IBM XL C/C++ for AIX, V11.1 (5724-X13) > Version: 11.01..0009 > $ xlC_r -qVersion > IBM XL C/C++ for AIX, V11.1 (5724-X13) > Version: 11.01..0009 > AIX 1 6 00F8A90A4C00 >Reporter: Alexey Roytman >Assignee: Scott Cantor >Priority: Major > Fix For: 3.2.3 > > > When running tests on AIX, they crash a lot. > One example is a RangeTest: > bash-4.3$ dbx ./tests/.libs/RangeTest > (dbx) run > IOT/Abort trap in pthread_kill at 0x952eed4 ($t1) > 0x952eed4 (pthread_kill+0xd4) e8410028 ld r2,0x28(r1) > (dbx) where > pthread_kill(??, ??) at 0x952eed4 > _p_raise(??) at 0x952e708 > raise.raise(??) at 0x902c34c > abort() at 0x9082de4 > std::myabort()() at 0x9000babad8c > std::terminate()() at 0x9000baba2ec > exceptio.std::terminate().terminate()() at 0x9000babae8c > __DoThrowV6() at 0x9000babd218 > xercesc_3_2::DOMParentNode::getContainingNodeImpl() const() at > 0x9005c27abac > xercesc_3_2::DOMParentNode::insertBefore(xercesc_3_2::DOMNode*,xercesc_3_2::DOMNode*)() > at 0x9005c27af60 > xercesc_3_2::DOMDocumentImpl::insertBefore(xercesc_3_2::DOMNode*,xercesc_3_2::DOMNode*)() > at 0x9005c20500c > xercesc_3_2::DOMDocumentImpl::appendChild(xercesc_3_2::DOMNode*)() at > 0x9005c201cf0 > main() at 0x10958 > (dbx) quit -- 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-2186) undef symbols on HPUX for ArrayJanitor
[ https://issues.apache.org/jira/browse/XERCESC-2186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor updated XERCESC-2186: -- Fix Version/s: 3.2.3 > undef symbols on HPUX for ArrayJanitor > -- > > Key: XERCESC-2186 > URL: https://issues.apache.org/jira/browse/XERCESC-2186 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.2 > Environment: HP-UX B.11.31 U ia64 > aCC: HP C/aC++ B3910B A.06.28 [Nov 21 2013] >Reporter: Alexey Roytman >Priority: Major > Fix For: 3.2.3 > > > When compiling xerces-c 3.2.2 on HP-UX 11.31 with HP-UX C++ compiler A.06.28, > there are undefined symbols in the shared library: > CXXLD PSVIWriter > fails because of some missing symbols. > nm ./src/.libs/libxerces-c.so | grep ArrayJanitor | c++filt | grep UNDEF > [5645] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::reset(unsigned char*,xercesc_3_2::MemoryManager*) > [13918] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::release() > [10852] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::ArrayJanitor(unsigned char*)(complete) > [4694] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::ArrayJanitor(unsigned char*,xercesc_3_2::MemoryManager*)(complete) > [10308] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::~ArrayJanitor()(complete) > [5344] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::reset(unsigned short*,xercesc_3_2::MemoryManager*) > [13909] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::release() > [10884] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::ArrayJanitor(unsigned short*)(complete) > [12717] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::ArrayJanitor(unsigned short*,xercesc_3_2::MemoryManager*)(complete) > [10227] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::~ArrayJanitor()(complete) > [5251] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::get() const > [8674] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor char>::operator[](unsigned long) const > [3757] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::get() const > [8931] | 0| 0|FUNC |GLOB |0| UNDEF|xercesc_3_2::ArrayJanitor short>::operator[](unsigned long) const > > Look at these 2 lines in Janitor.hpp: > 158 XERCES_TEMPLATE_EXTERN template class XMLUTIL_EXPORT > ArrayJanitor; > 159 XERCES_TEMPLATE_EXTERN template class XMLUTIL_EXPORT ArrayJanitor; > When I comment out these 2 lines, the builds succeeds. I did not run the > tests... > The xerces-c 3.2.1 was built on the same environment successfully. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2187) DOM tests crash on AIX
[ https://issues.apache.org/jira/browse/XERCESC-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor resolved XERCESC-2187. --- Resolution: Fixed > DOM tests crash on AIX > -- > > Key: XERCESC-2187 > URL: https://issues.apache.org/jira/browse/XERCESC-2187 > Project: Xerces-C++ > Issue Type: Bug > Components: DOM >Affects Versions: 3.2.1, 3.2.2 > Environment: $ cc_r -qVersion > IBM XL C/C++ for AIX, V11.1 (5724-X13) > Version: 11.01..0009 > $ xlC_r -qVersion > IBM XL C/C++ for AIX, V11.1 (5724-X13) > Version: 11.01..0009 > AIX 1 6 00F8A90A4C00 >Reporter: Alexey Roytman >Assignee: Scott Cantor >Priority: Major > Fix For: 3.2.3 > > > When running tests on AIX, they crash a lot. > One example is a RangeTest: > bash-4.3$ dbx ./tests/.libs/RangeTest > (dbx) run > IOT/Abort trap in pthread_kill at 0x952eed4 ($t1) > 0x952eed4 (pthread_kill+0xd4) e8410028 ld r2,0x28(r1) > (dbx) where > pthread_kill(??, ??) at 0x952eed4 > _p_raise(??) at 0x952e708 > raise.raise(??) at 0x902c34c > abort() at 0x9082de4 > std::myabort()() at 0x9000babad8c > std::terminate()() at 0x9000baba2ec > exceptio.std::terminate().terminate()() at 0x9000babae8c > __DoThrowV6() at 0x9000babd218 > xercesc_3_2::DOMParentNode::getContainingNodeImpl() const() at > 0x9005c27abac > xercesc_3_2::DOMParentNode::insertBefore(xercesc_3_2::DOMNode*,xercesc_3_2::DOMNode*)() > at 0x9005c27af60 > xercesc_3_2::DOMDocumentImpl::insertBefore(xercesc_3_2::DOMNode*,xercesc_3_2::DOMNode*)() > at 0x9005c20500c > xercesc_3_2::DOMDocumentImpl::appendChild(xercesc_3_2::DOMNode*)() at > 0x9005c201cf0 > main() at 0x10958 > (dbx) quit -- 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-2187) DOM tests crash on AIX
[ https://issues.apache.org/jira/browse/XERCESC-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17072952#comment-17072952 ] Scott Cantor commented on XERCESC-2187: --- Applied to both branches. > DOM tests crash on AIX > -- > > Key: XERCESC-2187 > URL: https://issues.apache.org/jira/browse/XERCESC-2187 > Project: Xerces-C++ > Issue Type: Bug > Components: DOM >Affects Versions: 3.2.1, 3.2.2 > Environment: $ cc_r -qVersion > IBM XL C/C++ for AIX, V11.1 (5724-X13) > Version: 11.01..0009 > $ xlC_r -qVersion > IBM XL C/C++ for AIX, V11.1 (5724-X13) > Version: 11.01..0009 > AIX 1 6 00F8A90A4C00 >Reporter: Alexey Roytman >Assignee: Scott Cantor >Priority: Major > Fix For: 3.2.3 > > > When running tests on AIX, they crash a lot. > One example is a RangeTest: > bash-4.3$ dbx ./tests/.libs/RangeTest > (dbx) run > IOT/Abort trap in pthread_kill at 0x952eed4 ($t1) > 0x952eed4 (pthread_kill+0xd4) e8410028 ld r2,0x28(r1) > (dbx) where > pthread_kill(??, ??) at 0x952eed4 > _p_raise(??) at 0x952e708 > raise.raise(??) at 0x902c34c > abort() at 0x9082de4 > std::myabort()() at 0x9000babad8c > std::terminate()() at 0x9000baba2ec > exceptio.std::terminate().terminate()() at 0x9000babae8c > __DoThrowV6() at 0x9000babd218 > xercesc_3_2::DOMParentNode::getContainingNodeImpl() const() at > 0x9005c27abac > xercesc_3_2::DOMParentNode::insertBefore(xercesc_3_2::DOMNode*,xercesc_3_2::DOMNode*)() > at 0x9005c27af60 > xercesc_3_2::DOMDocumentImpl::insertBefore(xercesc_3_2::DOMNode*,xercesc_3_2::DOMNode*)() > at 0x9005c20500c > xercesc_3_2::DOMDocumentImpl::appendChild(xercesc_3_2::DOMNode*)() at > 0x9005c201cf0 > main() at 0x10958 > (dbx) quit -- 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-2187) DOM tests crash on AIX
[ https://issues.apache.org/jira/browse/XERCESC-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor updated XERCESC-2187: -- Fix Version/s: 3.2.3 > DOM tests crash on AIX > -- > > Key: XERCESC-2187 > URL: https://issues.apache.org/jira/browse/XERCESC-2187 > Project: Xerces-C++ > Issue Type: Bug > Components: DOM >Affects Versions: 3.2.1, 3.2.2 > Environment: $ cc_r -qVersion > IBM XL C/C++ for AIX, V11.1 (5724-X13) > Version: 11.01..0009 > $ xlC_r -qVersion > IBM XL C/C++ for AIX, V11.1 (5724-X13) > Version: 11.01..0009 > AIX 1 6 00F8A90A4C00 >Reporter: Alexey Roytman >Assignee: Scott Cantor >Priority: Major > Fix For: 3.2.3 > > > When running tests on AIX, they crash a lot. > One example is a RangeTest: > bash-4.3$ dbx ./tests/.libs/RangeTest > (dbx) run > IOT/Abort trap in pthread_kill at 0x952eed4 ($t1) > 0x952eed4 (pthread_kill+0xd4) e8410028 ld r2,0x28(r1) > (dbx) where > pthread_kill(??, ??) at 0x952eed4 > _p_raise(??) at 0x952e708 > raise.raise(??) at 0x902c34c > abort() at 0x9082de4 > std::myabort()() at 0x9000babad8c > std::terminate()() at 0x9000baba2ec > exceptio.std::terminate().terminate()() at 0x9000babae8c > __DoThrowV6() at 0x9000babd218 > xercesc_3_2::DOMParentNode::getContainingNodeImpl() const() at > 0x9005c27abac > xercesc_3_2::DOMParentNode::insertBefore(xercesc_3_2::DOMNode*,xercesc_3_2::DOMNode*)() > at 0x9005c27af60 > xercesc_3_2::DOMDocumentImpl::insertBefore(xercesc_3_2::DOMNode*,xercesc_3_2::DOMNode*)() > at 0x9005c20500c > xercesc_3_2::DOMDocumentImpl::appendChild(xercesc_3_2::DOMNode*)() at > 0x9005c201cf0 > main() at 0x10958 > (dbx) quit -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Assigned] (XERCESC-2187) DOM tests crash on AIX
[ https://issues.apache.org/jira/browse/XERCESC-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cantor reassigned XERCESC-2187: - Assignee: Scott Cantor > DOM tests crash on AIX > -- > > Key: XERCESC-2187 > URL: https://issues.apache.org/jira/browse/XERCESC-2187 > Project: Xerces-C++ > Issue Type: Bug > Components: DOM >Affects Versions: 3.2.1, 3.2.2 > Environment: $ cc_r -qVersion > IBM XL C/C++ for AIX, V11.1 (5724-X13) > Version: 11.01..0009 > $ xlC_r -qVersion > IBM XL C/C++ for AIX, V11.1 (5724-X13) > Version: 11.01..0009 > AIX 1 6 00F8A90A4C00 >Reporter: Alexey Roytman >Assignee: Scott Cantor >Priority: Major > > When running tests on AIX, they crash a lot. > One example is a RangeTest: > bash-4.3$ dbx ./tests/.libs/RangeTest > (dbx) run > IOT/Abort trap in pthread_kill at 0x952eed4 ($t1) > 0x952eed4 (pthread_kill+0xd4) e8410028 ld r2,0x28(r1) > (dbx) where > pthread_kill(??, ??) at 0x952eed4 > _p_raise(??) at 0x952e708 > raise.raise(??) at 0x902c34c > abort() at 0x9082de4 > std::myabort()() at 0x9000babad8c > std::terminate()() at 0x9000baba2ec > exceptio.std::terminate().terminate()() at 0x9000babae8c > __DoThrowV6() at 0x9000babd218 > xercesc_3_2::DOMParentNode::getContainingNodeImpl() const() at > 0x9005c27abac > xercesc_3_2::DOMParentNode::insertBefore(xercesc_3_2::DOMNode*,xercesc_3_2::DOMNode*)() > at 0x9005c27af60 > xercesc_3_2::DOMDocumentImpl::insertBefore(xercesc_3_2::DOMNode*,xercesc_3_2::DOMNode*)() > at 0x9005c20500c > xercesc_3_2::DOMDocumentImpl::appendChild(xercesc_3_2::DOMNode*)() at > 0x9005c201cf0 > main() at 0x10958 > (dbx) quit -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[xerces-c] branch xerces-3.2 updated: XERCESC-2187 / others - DOM tests crashing on unsupported platforms
This is an automated email from the ASF dual-hosted git repository. scantor pushed a commit to branch xerces-3.2 in repository https://gitbox.apache.org/repos/asf/xerces-c.git The following commit(s) were added to refs/heads/xerces-3.2 by this push: new 0d3989f XERCESC-2187 / others - DOM tests crashing on unsupported platforms 0d3989f is described below commit 0d3989faf03ef09e1c991215e9eb603f38e820cf Author: Scott Cantor AuthorDate: Wed Apr 1 12:37:37 2020 -0400 XERCESC-2187 / others - DOM tests crashing on unsupported platforms --- doc/build.xml| 6 -- src/xercesc/util/Janitor.hpp | 4 ++-- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/doc/build.xml b/doc/build.xml index 3f706b9..aedb4bd 100644 --- a/doc/build.xml +++ b/doc/build.xml @@ -572,14 +572,16 @@ AIX PowerPC IBM XL C++ ./configure CXX=xlC_r CC=xlc_r - gmake libxerces_c_la_LDFLAGS=-qmkshrobj + gmake libxerces_c_la_LDFLAGS=-qmkshrobj + (for xlC v11-v13, libxerces_c_la_LDFLAGS is not needed, but CXXFLAGS=-rtti is needed otherwise RTTI is disabled by default) AIX PowerPC-64 IBM XL C++ export OBJECT_MODE=64 ./configure CXX=xlC_r CC=xlc_r CXXFLAGS=-q64 CFLAGS=-q64 - gmake libxerces_c_la_LDFLAGS=-qmkshrobj + gmake libxerces_c_la_LDFLAGS=-qmkshrobj + (for xlC v11-v13, libxerces_c_la_LDFLAGS is not needed, but CXXFLAGS="-q64 -rtti" is needed otherwise RTTI is disabled by default) HP-UX IA-64-32 diff --git a/src/xercesc/util/Janitor.hpp b/src/xercesc/util/Janitor.hpp index 24ff372..cf06e67 100644 --- a/src/xercesc/util/Janitor.hpp +++ b/src/xercesc/util/Janitor.hpp @@ -154,10 +154,10 @@ private : MFPTfToCall; }; - +#if defined(__GNUC__) || (! defined(_AIX) && ! defined(__hpux) && ! defined(__sun)) XERCES_TEMPLATE_EXTERN template class XMLUTIL_EXPORT ArrayJanitor; XERCES_TEMPLATE_EXTERN template class XMLUTIL_EXPORT ArrayJanitor; - +#endif XERCES_CPP_NAMESPACE_END - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[xerces-c] branch master updated: XERCESC-2187 / others - DOM tests crashing on unsupported platforms
This is an automated email from the ASF dual-hosted git repository. scantor pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/xerces-c.git The following commit(s) were added to refs/heads/master by this push: new d00c6a5 XERCESC-2187 / others - DOM tests crashing on unsupported platforms d00c6a5 is described below commit d00c6a50672d57628d6629e2215a6f6c7acd0bbc Author: Scott Cantor AuthorDate: Wed Apr 1 12:37:37 2020 -0400 XERCESC-2187 / others - DOM tests crashing on unsupported platforms --- doc/build.xml| 6 -- src/xercesc/util/Janitor.hpp | 4 ++-- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/doc/build.xml b/doc/build.xml index 3f706b9..aedb4bd 100644 --- a/doc/build.xml +++ b/doc/build.xml @@ -572,14 +572,16 @@ AIX PowerPC IBM XL C++ ./configure CXX=xlC_r CC=xlc_r - gmake libxerces_c_la_LDFLAGS=-qmkshrobj + gmake libxerces_c_la_LDFLAGS=-qmkshrobj + (for xlC v11-v13, libxerces_c_la_LDFLAGS is not needed, but CXXFLAGS=-rtti is needed otherwise RTTI is disabled by default) AIX PowerPC-64 IBM XL C++ export OBJECT_MODE=64 ./configure CXX=xlC_r CC=xlc_r CXXFLAGS=-q64 CFLAGS=-q64 - gmake libxerces_c_la_LDFLAGS=-qmkshrobj + gmake libxerces_c_la_LDFLAGS=-qmkshrobj + (for xlC v11-v13, libxerces_c_la_LDFLAGS is not needed, but CXXFLAGS="-q64 -rtti" is needed otherwise RTTI is disabled by default) HP-UX IA-64-32 diff --git a/src/xercesc/util/Janitor.hpp b/src/xercesc/util/Janitor.hpp index 24ff372..cf06e67 100644 --- a/src/xercesc/util/Janitor.hpp +++ b/src/xercesc/util/Janitor.hpp @@ -154,10 +154,10 @@ private : MFPTfToCall; }; - +#if defined(__GNUC__) || (! defined(_AIX) && ! defined(__hpux) && ! defined(__sun)) XERCES_TEMPLATE_EXTERN template class XMLUTIL_EXPORT ArrayJanitor; XERCES_TEMPLATE_EXTERN template class XMLUTIL_EXPORT ArrayJanitor; - +#endif XERCES_CPP_NAMESPACE_END - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Closed] (XERCESC-2189) XMLChar with NEED_TO_GEN_TABLE has 2 buffer out of bounds reads
[
https://issues.apache.org/jira/browse/XERCESC-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Cantor closed XERCESC-2189.
-
> XMLChar with NEED_TO_GEN_TABLE has 2 buffer out of bounds reads
> ---
>
> Key: XERCESC-2189
> URL: https://issues.apache.org/jira/browse/XERCESC-2189
> Project: Xerces-C++
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 3.2.2
>Reporter: Alexey Roytman
>Assignee: Scott Cantor
>Priority: Minor
> Fix For: 3.2.3
>
>
> During scan with cppcheck 1.90, the XMLChar's code under #ifdef
> NEED_TO_GEN_TABLE has two out-of-bounds reads in initCharFlagTable() and in
> initCharFlagTable1_1():
> fprintf(outFl, "XMLByte ...[0x1] =\n{");
> for (unsigned int index = 0; index <= 0x; index += 16)
> {
> fprintf(...
> , (unsigned int)gTmpCharTable[index]
> ...
> , (unsigned int)gTmpCharTable[index+15]);
> }
> fprintf(outFl, "};\n");
>
> But the gTmpCharTable's size is 0x (which is 1 less than 0x1), and at
> the last loop, when index==0xFFF0, we access gTmpCharTable[0xFFF0+15] which
> is gTmpCharTable[0x], which is 1 after the end of buffer.
>
> I'd say that gTmpCharTable shall have 0x1 elements, and not 0x...
>
--
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-2189) XMLChar with NEED_TO_GEN_TABLE has 2 buffer out of bounds reads
[
https://issues.apache.org/jira/browse/XERCESC-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Cantor updated XERCESC-2189:
--
Issue Type: Bug (was: New Feature)
> XMLChar with NEED_TO_GEN_TABLE has 2 buffer out of bounds reads
> ---
>
> Key: XERCESC-2189
> URL: https://issues.apache.org/jira/browse/XERCESC-2189
> Project: Xerces-C++
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 3.2.2
>Reporter: Alexey Roytman
>Assignee: Scott Cantor
>Priority: Minor
> Fix For: 3.2.3
>
>
> During scan with cppcheck 1.90, the XMLChar's code under #ifdef
> NEED_TO_GEN_TABLE has two out-of-bounds reads in initCharFlagTable() and in
> initCharFlagTable1_1():
> fprintf(outFl, "XMLByte ...[0x1] =\n{");
> for (unsigned int index = 0; index <= 0x; index += 16)
> {
> fprintf(...
> , (unsigned int)gTmpCharTable[index]
> ...
> , (unsigned int)gTmpCharTable[index+15]);
> }
> fprintf(outFl, "};\n");
>
> But the gTmpCharTable's size is 0x (which is 1 less than 0x1), and at
> the last loop, when index==0xFFF0, we access gTmpCharTable[0xFFF0+15] which
> is gTmpCharTable[0x], which is 1 after the end of buffer.
>
> I'd say that gTmpCharTable shall have 0x1 elements, and not 0x...
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Assigned] (XERCESC-2189) XMLChar with NEED_TO_GEN_TABLE has 2 buffer out of bounds reads
[
https://issues.apache.org/jira/browse/XERCESC-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Cantor reassigned XERCESC-2189:
-
Assignee: Scott Cantor
> XMLChar with NEED_TO_GEN_TABLE has 2 buffer out of bounds reads
> ---
>
> Key: XERCESC-2189
> URL: https://issues.apache.org/jira/browse/XERCESC-2189
> Project: Xerces-C++
> Issue Type: New Feature
> Components: Utilities
>Affects Versions: 3.2.2
>Reporter: Alexey Roytman
>Assignee: Scott Cantor
>Priority: Minor
> Fix For: 3.2.3
>
>
> During scan with cppcheck 1.90, the XMLChar's code under #ifdef
> NEED_TO_GEN_TABLE has two out-of-bounds reads in initCharFlagTable() and in
> initCharFlagTable1_1():
> fprintf(outFl, "XMLByte ...[0x1] =\n{");
> for (unsigned int index = 0; index <= 0x; index += 16)
> {
> fprintf(...
> , (unsigned int)gTmpCharTable[index]
> ...
> , (unsigned int)gTmpCharTable[index+15]);
> }
> fprintf(outFl, "};\n");
>
> But the gTmpCharTable's size is 0x (which is 1 less than 0x1), and at
> the last loop, when index==0xFFF0, we access gTmpCharTable[0xFFF0+15] which
> is gTmpCharTable[0x], which is 1 after the end of buffer.
>
> I'd say that gTmpCharTable shall have 0x1 elements, and not 0x...
>
--
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-2189) XMLChar with NEED_TO_GEN_TABLE has 2 buffer out of bounds reads
[
https://issues.apache.org/jira/browse/XERCESC-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Cantor updated XERCESC-2189:
--
Fix Version/s: 3.2.3
> XMLChar with NEED_TO_GEN_TABLE has 2 buffer out of bounds reads
> ---
>
> Key: XERCESC-2189
> URL: https://issues.apache.org/jira/browse/XERCESC-2189
> Project: Xerces-C++
> Issue Type: New Feature
> Components: Utilities
>Affects Versions: 3.2.2
>Reporter: Alexey Roytman
>Priority: Minor
> Fix For: 3.2.3
>
>
> During scan with cppcheck 1.90, the XMLChar's code under #ifdef
> NEED_TO_GEN_TABLE has two out-of-bounds reads in initCharFlagTable() and in
> initCharFlagTable1_1():
> fprintf(outFl, "XMLByte ...[0x1] =\n{");
> for (unsigned int index = 0; index <= 0x; index += 16)
> {
> fprintf(...
> , (unsigned int)gTmpCharTable[index]
> ...
> , (unsigned int)gTmpCharTable[index+15]);
> }
> fprintf(outFl, "};\n");
>
> But the gTmpCharTable's size is 0x (which is 1 less than 0x1), and at
> the last loop, when index==0xFFF0, we access gTmpCharTable[0xFFF0+15] which
> is gTmpCharTable[0x], which is 1 after the end of buffer.
>
> I'd say that gTmpCharTable shall have 0x1 elements, and not 0x...
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2189) XMLChar with NEED_TO_GEN_TABLE has 2 buffer out of bounds reads
[
https://issues.apache.org/jira/browse/XERCESC-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Cantor resolved XERCESC-2189.
---
Resolution: Fixed
Applied to both branches. The code involved isn't really ever run of course.
> XMLChar with NEED_TO_GEN_TABLE has 2 buffer out of bounds reads
> ---
>
> Key: XERCESC-2189
> URL: https://issues.apache.org/jira/browse/XERCESC-2189
> Project: Xerces-C++
> Issue Type: New Feature
> Components: Utilities
>Affects Versions: 3.2.2
>Reporter: Alexey Roytman
>Assignee: Scott Cantor
>Priority: Minor
> Fix For: 3.2.3
>
>
> During scan with cppcheck 1.90, the XMLChar's code under #ifdef
> NEED_TO_GEN_TABLE has two out-of-bounds reads in initCharFlagTable() and in
> initCharFlagTable1_1():
> fprintf(outFl, "XMLByte ...[0x1] =\n{");
> for (unsigned int index = 0; index <= 0x; index += 16)
> {
> fprintf(...
> , (unsigned int)gTmpCharTable[index]
> ...
> , (unsigned int)gTmpCharTable[index+15]);
> }
> fprintf(outFl, "};\n");
>
> But the gTmpCharTable's size is 0x (which is 1 less than 0x1), and at
> the last loop, when index==0xFFF0, we access gTmpCharTable[0xFFF0+15] which
> is gTmpCharTable[0x], which is 1 after the end of buffer.
>
> I'd say that gTmpCharTable shall have 0x1 elements, and not 0x...
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[xerces-c] branch xerces-3.2 updated: XERCESC-2189 - XMLChar with NEED_TO_GEN_TABLE has 2 buffer out of bounds reads
This is an automated email from the ASF dual-hosted git repository. scantor pushed a commit to branch xerces-3.2 in repository https://gitbox.apache.org/repos/asf/xerces-c.git The following commit(s) were added to refs/heads/xerces-3.2 by this push: new c9c5f42 XERCESC-2189 - XMLChar with NEED_TO_GEN_TABLE has 2 buffer out of bounds reads c9c5f42 is described below commit c9c5f4294bef94e363f6b5956731161fac264938 Author: Scott Cantor AuthorDate: Wed Apr 1 12:28:10 2020 -0400 XERCESC-2189 - XMLChar with NEED_TO_GEN_TABLE has 2 buffer out of bounds reads --- src/xercesc/util/XMLChar.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/xercesc/util/XMLChar.cpp b/src/xercesc/util/XMLChar.cpp index 2d8b13c..46a61da 100644 --- a/src/xercesc/util/XMLChar.cpp +++ b/src/xercesc/util/XMLChar.cpp @@ -8837,7 +8837,7 @@ XMLByte XMLChar1_1::fgCharCharsTable1_1[0x1] = #include -static XMLCh gTmpCharTable[0x]; +static XMLCh gTmpCharTable[0x1]; static void initOneTable(const XMLCh* consttheTable , const XMLByte theMask) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[xerces-c] branch master updated: XERCESC-2189 - XMLChar with NEED_TO_GEN_TABLE has 2 buffer out of bounds reads
This is an automated email from the ASF dual-hosted git repository. scantor pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/xerces-c.git The following commit(s) were added to refs/heads/master by this push: new a91b38c XERCESC-2189 - XMLChar with NEED_TO_GEN_TABLE has 2 buffer out of bounds reads a91b38c is described below commit a91b38c78cdf14ed4bc0b7655b985128f9a51065 Author: Scott Cantor AuthorDate: Wed Apr 1 12:28:10 2020 -0400 XERCESC-2189 - XMLChar with NEED_TO_GEN_TABLE has 2 buffer out of bounds reads --- src/xercesc/util/XMLChar.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/xercesc/util/XMLChar.cpp b/src/xercesc/util/XMLChar.cpp index 2d8b13c..46a61da 100644 --- a/src/xercesc/util/XMLChar.cpp +++ b/src/xercesc/util/XMLChar.cpp @@ -8837,7 +8837,7 @@ XMLByte XMLChar1_1::fgCharCharsTable1_1[0x1] = #include -static XMLCh gTmpCharTable[0x]; +static XMLCh gTmpCharTable[0x1]; static void initOneTable(const XMLCh* consttheTable , const XMLByte theMask) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2190) deprecated GetVersionEx
[
https://issues.apache.org/jira/browse/XERCESC-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17072934#comment-17072934
]
Scott Cantor commented on XERCESC-2190:
---
I wouldn't be prepared to make a unilateral decision for the project that
support for anything older be dropped. I don't personally need it but I can't
speak for others.
> deprecated GetVersionEx
> ---
>
> Key: XERCESC-2190
> URL: https://issues.apache.org/jira/browse/XERCESC-2190
> Project: Xerces-C++
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Aleksey Dobrunov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hello.
> *"GetVersionEx* may be altered or unavailable for releases after Windows 8.1.
> Instead, use the [Version Helper
> functions"|https://docs.microsoft.com/windows/desktop/SysInfo/version-helper-apis]
>
> [https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getversionexa]
> .
> {code:java}
> C:\Work\code\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(323):
> warning C4996: 'GetVersionExA': was declared deprecated
> C:\Program Files (x86)\Windows
> Kits\10\include\10.0.18362.0\um\sysinfoapi.h(387): note: see declaration of
> 'GetVersionExA'
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2193) Validation error for prefix declaration on element whose value uses a prefix
[ https://issues.apache.org/jira/browse/XERCESC-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17072932#comment-17072932 ] Scott Cantor commented on XERCESC-2193: --- This might (emphasis) might be tractable for me to look at if a proper test case with schema were provided so I can quickly reproduce and validate any change using one of the command line tools. > Validation error for prefix declaration on element whose value uses a prefix > > > Key: XERCESC-2193 > URL: https://issues.apache.org/jira/browse/XERCESC-2193 > Project: Xerces-C++ > Issue Type: Bug > Components: Validating Parser (XML Schema) >Affects Versions: 3.2.2 > Environment: Linux >Reporter: Herm Fischer >Priority: Major > > Xerces schema validation reports the prefix is undefined when QName content > of an element is using a prefix defined on the element (works fine with > Xerces-J, etc). > http://example.com/this;>this:someArc > validation message: undefined prefix in QName value 'this:someArc' > Is there a parameter, usage pattern, or code patch which will make this > validate cleanly? (isPrefixUnknown seems to look in element stack instead of > looking first at current element?) -- 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] [Closed] (XERCESC-2194) Including Xerces_autoconf_config.hpp on Windows fails due to undefined ssize_t
[
https://issues.apache.org/jira/browse/XERCESC-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Cantor closed XERCESC-2194.
-
> Including Xerces_autoconf_config.hpp on Windows fails due to undefined ssize_t
> --
>
> Key: XERCESC-2194
> URL: https://issues.apache.org/jira/browse/XERCESC-2194
> Project: Xerces-C++
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.2.2
>Reporter: Rasmus Thomsen
>Assignee: Scott Cantor
>Priority: Major
> Fix For: 3.2.3
>
>
> When including Xerces_autoconf_config.hpp on Windows the following error
> messages:
>
> {code:cpp}
> error C4430: Fehlender Typspezifizierer - int wird angenommen. Hinweis:
> "default-int" wird von C++ nicht unterstützt.
> error C2146: Syntaxfehler: Fehlendes ";" vor Bezeichner "XMLSSize_t"
> {code}
> (Sorry that these are in German - they translate to "Missing type specifier -
> assuming int" and "syntax error: missing ";" before identifier "XMLSSize_t")
> Apparently ssize_t is a POSIX extension and as such isn't available in MSVC
> (by default?)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2194) Including Xerces_autoconf_config.hpp on Windows fails due to undefined ssize_t
[
https://issues.apache.org/jira/browse/XERCESC-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Cantor resolved XERCESC-2194.
---
Resolution: Fixed
> Including Xerces_autoconf_config.hpp on Windows fails due to undefined ssize_t
> --
>
> Key: XERCESC-2194
> URL: https://issues.apache.org/jira/browse/XERCESC-2194
> Project: Xerces-C++
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.2.2
>Reporter: Rasmus Thomsen
>Assignee: Scott Cantor
>Priority: Major
> Fix For: 3.2.3
>
>
> When including Xerces_autoconf_config.hpp on Windows the following error
> messages:
>
> {code:cpp}
> error C4430: Fehlender Typspezifizierer - int wird angenommen. Hinweis:
> "default-int" wird von C++ nicht unterstützt.
> error C2146: Syntaxfehler: Fehlendes ";" vor Bezeichner "XMLSSize_t"
> {code}
> (Sorry that these are in German - they translate to "Missing type specifier -
> assuming int" and "syntax error: missing ";" before identifier "XMLSSize_t")
> Apparently ssize_t is a POSIX extension and as such isn't available in MSVC
> (by default?)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2194) Including Xerces_autoconf_config.hpp on Windows fails due to undefined ssize_t
[
https://issues.apache.org/jira/browse/XERCESC-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17072926#comment-17072926
]
Scott Cantor commented on XERCESC-2194:
---
Master:
aacdef3fa74bea84ff1ff4cd699782bcc080873f
3.2 branch:
526624138f1f755688510908b996d9601a2ed69d
I can't do anything with the pull request but it should be removed.
> Including Xerces_autoconf_config.hpp on Windows fails due to undefined ssize_t
> --
>
> Key: XERCESC-2194
> URL: https://issues.apache.org/jira/browse/XERCESC-2194
> Project: Xerces-C++
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.2.2
>Reporter: Rasmus Thomsen
>Assignee: Scott Cantor
>Priority: Major
> Fix For: 3.2.3
>
>
> When including Xerces_autoconf_config.hpp on Windows the following error
> messages:
>
> {code:cpp}
> error C4430: Fehlender Typspezifizierer - int wird angenommen. Hinweis:
> "default-int" wird von C++ nicht unterstützt.
> error C2146: Syntaxfehler: Fehlendes ";" vor Bezeichner "XMLSSize_t"
> {code}
> (Sorry that these are in German - they translate to "Missing type specifier -
> assuming int" and "syntax error: missing ";" before identifier "XMLSSize_t")
> Apparently ssize_t is a POSIX extension and as such isn't available in MSVC
> (by default?)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[xerces-c] branch xerces-3.2 updated: XERCESC-2194 - Windows/cmake fails due to undefined ssize_t
This is an automated email from the ASF dual-hosted git repository.
scantor pushed a commit to branch xerces-3.2
in repository https://gitbox.apache.org/repos/asf/xerces-c.git
The following commit(s) were added to refs/heads/xerces-3.2 by this push:
new 5266241 XERCESC-2194 - Windows/cmake fails due to undefined ssize_t
5266241 is described below
commit 526624138f1f755688510908b996d9601a2ed69d
Author: Scott Cantor
AuthorDate: Wed Apr 1 12:12:31 2020 -0400
XERCESC-2194 - Windows/cmake fails due to undefined ssize_t
---
cmake/XercesIntTypes.cmake | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cmake/XercesIntTypes.cmake b/cmake/XercesIntTypes.cmake
index 6ad7dd3..85c94e1 100644
--- a/cmake/XercesIntTypes.cmake
+++ b/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)
set(XERCES_SIZE_T size_t)
set(XERCES_SIZE_MAX SIZE_MAX)
else()
set(XERCES_SIZE_T "unsigned long")
set(XERCES_SIZE_MAX ULONG_MAX)
endif()
-if(SIZEOF_SSIZE_T)
+if(HAVE_SIZEOF_SSIZE_T)
set(XERCES_SSIZE_T ssize_t)
set(XERCES_SSIZE_MAX SSIZE_MAX)
else()
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
[xerces-c] branch master updated: XERCESC-2194 - Windows/cmake fails due to undefined ssize_t
This is an automated email from the ASF dual-hosted git repository.
scantor pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/xerces-c.git
The following commit(s) were added to refs/heads/master by this push:
new aacdef3 XERCESC-2194 - Windows/cmake fails due to undefined ssize_t
aacdef3 is described below
commit aacdef3fa74bea84ff1ff4cd699782bcc080873f
Author: Scott Cantor
AuthorDate: Wed Apr 1 12:12:31 2020 -0400
XERCESC-2194 - Windows/cmake fails due to undefined ssize_t
---
cmake/XercesIntTypes.cmake | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cmake/XercesIntTypes.cmake b/cmake/XercesIntTypes.cmake
index 6ad7dd3..85c94e1 100644
--- a/cmake/XercesIntTypes.cmake
+++ b/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)
set(XERCES_SIZE_T size_t)
set(XERCES_SIZE_MAX SIZE_MAX)
else()
set(XERCES_SIZE_T "unsigned long")
set(XERCES_SIZE_MAX ULONG_MAX)
endif()
-if(SIZEOF_SSIZE_T)
+if(HAVE_SIZEOF_SSIZE_T)
set(XERCES_SSIZE_T ssize_t)
set(XERCES_SSIZE_MAX SSIZE_MAX)
else()
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
