DO NOT REPLY [Bug 20092] - Latest HEAD branch causes gcc internal failure.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Templates in Source-Files

Hi all, I just ported Version 2.2.0 to OS/2, using the VisualAge C++ V4.0 compiler. Since most OS/2 developers are using VisualAge C++ 3.0, OpenWatcom or gcc, I'm currently working on a build environment for VisualAge C++ 3.0 and I'm almost done ;-) But there are some problems with templates u

DO NOT REPLY [Bug 20413] - NetBSD does not compile

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DOM size limit?

Is there any sort of memory constraint on the size of a DOMDocument, and it's collective assoicated nodes? I'm getting mysterious segmentation violation inside getLocalName or getNodeType, when the program reaches approximately 80-90 MB of virtual storage usage, most of which is used by xerces (2.2

DO NOT REPLY [Bug 13191] - Multiple xsd:imports on the same namespace

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 20436] - Parser don't support Validating check.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 13191] - Multiple xsd:imports on the same namespace

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 20436] New: - Parser don't support Validating check.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 20435] - compile Error

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 20435] New: - compile Error

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: in search of ideas: how might one write a test that the parser nevercalls global new directly?

Hi Neil, Since you're allowed to override global new/delete, why not put an empty implementation within Xerces that calls the panic handler or the default static MemoryManager, and logs a message? I tried this on Win32 (with a little massaging of the code), Linux, and AIX and it seems to work

in search of ideas: how might one write a test that the parser never callsglobal new directly?

Hi folks, Now that we've implemented the new memory management framework, it would be nice to have some confidence that we're using it correctly and comprehensively. I'll shortly commit some tests that exercise per-parser handlers, and ensure that all memory that the handlers allocate is deleted,

DO NOT REPLY [Bug 20387] - SAX2Print crashes after reading schema

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: Build failure under cygwin

Aha! Well done! You found it. My installation had a previous set of includes in /usr/include. I don't how I acquired that. Because of the ordering of the include directives in the build (/usr/include BEFORE local build directories), the older includes were getting picked up during the build

DO NOT REPLY [Bug 20423] New: - DOMWriter does not handle % properly

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: lots of errors involving DOMString::~DOMString(void) when linking

Hi Michael, No, those version of GCC are not compatible, so you will need to be consistent with which version of GCC you use. I have no idea if Xerces 2.3 will build with 2.91.66 -- that's an awfully old version of GCC. You'll have to try it and see what happens. Dave

Re: Build failure under cygwin

Hi Webb, I just built CVS under cygwin this morning, and all went well. The only odd thing I notice from your error log is a reference to the Xerces 2.2 namespace; you won't get that from CVS or Xerces 2.3.0 source code. So I wonder how that's slipping in? Cheers, Neil Neil Graham XML Parser De

Build failure under cygwin

I am trying to build xerces-c under cygwin. My cygwin installation is up-to-date. I get this with the CVS release, as well, as the 2.3.0 source release. After running runConfig, during make, on the very first sourcefile, I get the error below. I followed posted instructions, or tried to. Did

DO NOT REPLY [Bug 20092] - Latest HEAD branch causes gcc internal failure.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

RE: Ownership of const XMLCh *

Every pointer that is returned is owned by the document. You shouldn't deallocate them. regards /Erik -Original Message- From: Colin Paul Adams [mailto:[EMAIL PROTECTED] Sent: den 2 juni 2003 16:52 To: [EMAIL PROTECTED] Subject: Ownership of const XMLCh * When a method such as DOMNode::

DO NOT REPLY [Bug 20092] - Latest HEAD branch causes gcc internal failure.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Ownership of const XMLCh *

When a method such as DOMNode::getLocalName() returns a const XMLCh *, is the user responsible for deallocating the memory pointed to by the pointer, or is it owned by the DOMImplementation? -- Colin Paul Adams Preston Lancashire ---

DO NOT REPLY [Bug 20413] - NetBSD does not compile

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 20413] - NetBSD does not compile

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: lots of errors involving DOMString::~DOMString(void) when linking

Dave, Thanks for the feedback. I built Xerces 2.3 using g++ (version 2.96 2731 Red Hat Linux 7.3 2.96-113). Then I built my C++ code, the code I am having trouble with, using egcs++ (gcc version egcs-2.91.66 19990314/Linux egcs-1.1.2 release). Is this the problem and if it is, is it possibl