terminator, and
rawBuffer() to always add the terminator. Can you check if the sources under
CVS fix your problem?
Thanks,
Alberto
> DOMString::appendData(const DOMString&) is broken
> -
>
> Key: XERCESC-398
>
: RE: [jira] Resolved: (XERCESC-392) Would like DOMString::operator< for
STL use, code provided
Looks good. Thank you.
> Would like DOMString::operator< for STL use, code provided
> --
>
> Key: XERCESC-392
>
Looks good. Thank you.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
ike DOMString::operator< for STL use, code provided
> --
>
> Key: XERCESC-392
> URL: http://nagoya.apache.org/jira/browse/XERCESC-392
> Project: Xerces-C++
> Type: Bug
> Components: DOM
>
[ http://nagoya.apache.org/jira/browse/XERCESC-398?page=history ]
Alberto Massari updated XERCESC-398:
Priority: Major
> DOMString::appendData(const DOMString&) is broken
> -
>
>
[ http://nagoya.apache.org/jira/browse/XERCESC-392?page=history ]
Alberto Massari updated XERCESC-392:
Priority: Major
> Would like DOMString::operator< for STL use, code pr
:
-
Key: XERCESC-50
Summary: DOMString bug
Type: Bug
Status: Closed
Resolution: CANNOT REPRODUCE
Project: Xerces-C++
Components:
DOM
Versions:
1.4
Assignee:
Reporter: faboire
Created: Wed, 2 May 2001 8:53 AM
Updated: Tue, 19 Oct
:
-
Key: XERCESC-197
Summary: DOMString::transcode does not always detect wcstombs errors
Type: Bug
Status: Closed
Resolution: WON'T FIX
Project: Xerces-C++
Components:
DOM
Versions:
1.5.1
Assignee:
Reporter: jclifford
Created: F
54350
-
View the issue:
http://issues.apache.org/jira/browse/XERCESC-398
Here is an overview of the issue:
-
Key: XERCESC-398
Summary: DOMString::appendData(const DOMS
DOMString all
the time.
DOMString DOM_Node::getNodeName() const
{
return fImpl->getNodeName().clone();
};
DOMString DOMString::clone() const
{
DOMString retString;
if (fHandle != 0)
retString.fHandle =
this->fHandle->cloneStringHandle();
return
Dear xerces-c-dev,
Currently we are using xereces 1.6 to read large
XML documents. However, we are experience performance
issue on DOM_Node::getNodeValue(),
DOM_Node::getNodeName() kind of functions.
They are constructing and destructing DOMString all
the time.
DOMString DOM_Node
: lots of errors involving
DOMString::~DOMString(void) when linking
06/02/2003 07:03
possible to build Xerces 2.3 using egcs++
2.91.66 ?
Thank you for any advice.
Michael
- Original message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Sun, 1 Jun 2003 23:57:02 -0700
Subject: Re: lots of errors involving DOMString::~DOMString(void) when
linking
> Hi,
>
> T
> Hi,
>
> Thanks for checking out my post.
>
> I am updating some existing C++ code on Linux (redhat 7.3) from Xerces
> 1.7 to 2.3. The migration help notes on the website have been a great
> help, but I am getting hundreds of linking errors and most of them seem
&
Hi,
Thanks for checking out my post.
I am updating some existing C++ code on Linux (redhat 7.3) from Xerces
1.7 to 2.3. The migration help notes on the website have been a great
help, but I am getting hundreds of linking errors and most of them seem
to involve DOMString::~DOMString. I am using
gzilla/show_bug.cgi?id=15535
Wrong pattern recognized by DOMString::patternMatch()
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RE
gzilla/show_bug.cgi?id=15535
Wrong pattern recognized by DOMString::patternMatch()
Summary: Wrong pattern recognized by DOMString::patternMatch()
Product: Xerces-C++
Version: 2.1.0
Platform: All
OS/Version: All
Status: NEW
Se
gzilla/show_bug.cgi?id=6122
DOMString::transcode() maybe have something wrong,
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RE
gt;
> To: <[EMAIL PROTECTED]>
> Sent: Monday, November 25, 2002 7:38 AM
> Subject: Re: DOMString
>
>
> >
> > I have checked the xerces-c_2_1_0D.dll, and indeed, there are no such
> > functions.
> > My question is: What to do if I want to use the new librar
link step correctly.
Tinny
- Original Message -
From: "Endre, MAGYARI" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 25, 2002 7:38 AM
Subject: Re: DOMString
>
> I have checked the xerces-c_2_1_0D.dll, and indeed, there are no such
> func
.obj) : error LNK2001: unresolved external symbol
> "__declspec(dllimport) public: long __thiscall
> SAXParseException::getLineNumber(void)const "
> (__imp_?getLineNumber@SAXParseException@@QBEJXZ)
> On Mon, 25 Nov 2002,
>
>
> Thank you for your help,
> Endre.
>
&
XParseException::getLineNumber(void)const "
(__imp_?getLineNumber@SAXParseException@@QBEJXZ)
On Mon, 25 Nov 2002,
Thank you for your help,
Endre.
Zdenek Nemec wrote:
> Dear Endre
> I am affraid there is no more DOMString use XMLCh* instead backed by
> XMLString
>
> see
Dear Endre
I am affraid there is no more DOMString use XMLCh* instead backed by
XMLString
see
http://xml.apache.org/xerces-c/program-dom.html#XMLCh
and
http://xml.apache.org/xerces-c/migrate_archive.html
for migration archive
zdenek
- Original Message -
From: "Endre, MAGYARI&quo
Dear List,
I'm migrating a code from Xerces 1.5.1 to Xerces 2.1.x,
I can not see a DOMString definition in the new include files.
(there is, but only in deprecated directories)
What to use instead of DomString? Is there a Migration guide
somewhere ?
Than
gzilla/show_bug.cgi?id=6122
DOMString::transcode() maybe have something wrong,
[EMAIL PROTECTED] changed:
What|Removed |Added
Keywords||PatchAva
> At 09:56 AM 10/06/2002 +0100, Gert van Spijker wrote:
> >Here is a code fragment, that works well on my system, from my MSVC code
> >that converts a nodes value to a MFC CString:
> >
> >char* pValue = XMLString::transcode( pNode->getNodeValue() );
> >CString Value = pValue;
> >delete pValue;
>
>
At 09:56 AM 10/06/2002 +0100, Gert van Spijker wrote:
>Here is a code fragment, that works well on my system, from my MSVC code
>that converts a nodes value to a MFC CString:
>
>char* pValue = XMLString::transcode( pNode->getNodeValue() );
>CString Value = pValue;
>delete pValue;
This code fragme
<< (ostream& target, const DOMString& s)
> {
> char *p = s.transcode();
> target << p;
> delete [] p;
> return target;
> }
>
> If the memory is allocated within a different heap (I am using the dll
> supplied for windows) how can the us
I am a little unclear on how this is supposed to work. In fact
this crashes on me all the time.
ostream& operator<< (ostream& target, const DOMString& s)
{
char *p = s.transcode();
target << p;
delete [] p;
return target;
}
If the memory is allocated wi
gzilla/show_bug.cgi?id=6122
DOMString::transcode() maybe have something wrong,
--- Additional Comments From [EMAIL PROTECTED] 2002-05-25 12:22
---
Linebreaks are accidentaly removed in my previous mail,
so I retry.
If the first size estimates fails(in char* DOMString::transcode()),
retP
gzilla/show_bug.cgi?id=6122
DOMString::transcode() maybe have something wrong,
[EMAIL PROTECTED] changed:
What|Removed |Added
OS/Version|Windows NT/2K |F
gzilla/show_bug.cgi?id=9263
At char *DOMString::transcode() - null terminations problems
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RE
gzilla/show_bug.cgi?id=9263
At char *DOMString::transcode() - null terminations problems
Summary: At char *DOMString::transcode() - null terminations
problems
Product: Xerces-C++
Version: 1.7.0
Platform: PC
OS/Versio
gzilla/show_bug.cgi?id=1650
DOMString error on LINUX
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|
Use the DOMStringToStdString function I write about in this page:
http://www.goingware.com/tips/xmlmemory.html
If you want to use an MFC CString instead of an STL string you could modify it
accordingly.
Mike
--
Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
ht
hi, prehaps it's very stupid question, but can somebody tell me how could i
use a DOMString as a normal string, for instance i was thinking using to
put the result of dom_element.getNodeValue() directly into a messageBox()
used in visual c++, the way i tried is typecast it like
This is similar to Bug #4565
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4565
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4565> )
I only wanted to offer another was to solve the problem.
And something else I forgot: The method I suggested
(DOMString::delete_buffer()) shoul
There is an alternative to using the transcode() member function in the
DOMString. There are methods in the class XMLString that allow a caller to
pass in buffers to transcode from/to. This means you allocate the memory for
the buffer and you are responsible for deleting it. The only tricky thing
Hi,
Weve found a problem in our code.
Our code is compiled in Visual C++, and uses the STL that comes with Visual
C++.
When we tried to delete (using delete []) the char* received from
DOMString::transcode(), our code crashed.
Our code is need to be with minimum dependency, so it is compiled
Are there any known issues using the 1.7.0 version of Xerces on MacOS X
[Carbon] in combination with MSL_All_Carbon.Shlib that could cause a crash
in DOMStringData::removeRef when trying to delete [] this? I double
checked, if there are double disposals [no luck] and the string data looks
valid r
gzilla/show_bug.cgi?id=7509
DOMString::appendData(const DOMString&) is broken
Summary: DOMString::appendData(const DOMString&) is broken
Product: Xerces-C++
Version: 1.6.0
Platform: All
OS/Version: Other
Status: NEW
S
gzilla/show_bug.cgi?id=7448
Would like DOMString::operator< for STL use, code provided
Summary: Would like DOMString::operator< for STL use, code
provided
Product: Xerces-C++
Version: 1.7.0
Platform: All
OS/Version: All
gzilla/show_bug.cgi?id=7022
DOMString::transcode ( and XMLString::transcode() ) fails on SuSE LINUX 7.3 for non
UTF-8 Strings
[EMAIL PROTECTED] changed:
What|Removed |Added
Stat
gzilla/show_bug.cgi?id=7022
DOMString::transcode ( and XMLString::transcode() ) fails on SuSE LINUX 7.3 for non
UTF-8 Strings
--- Additional Comments From [EMAIL PROTECTED] 2002-03-13 16:21 ---
In the meantime I found out that I just should use encoding="ISO-8859-1" or
whatever i
gzilla/show_bug.cgi?id=7022
DOMString::transcode ( and XMLString::transcode() ) fails on SuSE LINUX 7.3 for non
UTF-8 Strings
--- Additional Comments From [EMAIL PROTECTED] 2002-03-13 14:37 ---
I think that you may be confused about the role of XMLString::transcode() -
which is no
gzilla/show_bug.cgi?id=7022
DOMString::transcode ( and XMLString::transcode() ) fails on SuSE LINUX 7.3 for non
UTF-8 Strings
--- Additional Comments From [EMAIL PROTECTED] 2002-03-13 07:40 ---
The same occurs here on Sun Solaris, we try to parse a XML-Message and use
XMLString::transcod
gzilla/show_bug.cgi?id=7022
DOMString::transcode ( and XMLString::transcode() ) fails on SuSE LINUX 7.3 for non
UTF-8 Strings
Summary: DOMString::transcode ( and XMLString::transcode() )
fails on SuSE LINUX 7.3 for non UTF-8 Strings
Product: Xe
gzilla/show_bug.cgi?id=1601
DOMString bug
--- Additional Comments From [EMAIL PROTECTED] 2002-03-06 21:08 ---
Hi, there,
We have tried to reproduce it on our side, our configuration:
code base: xerces-c-src_2002-03-06.tar.gz
platform: Linux 2.2.12-20
gcc: egcs-2
Hello
I have some problms in determining how the DOMString represents its
values internally
The problem I have is the following
For the XML request
(Some Name In Russian Laung which is a Mix of Ascci and Non
ascii characters )
1) When The client sends a XML request , using the Visual
gzilla/show_bug.cgi?id=6122
DOMString::transcode() maybe have something wrong,
Summary: DOMString::transcode() maybe have something wrong,
Product: Xerces-C++
Version: 1.6.0
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Se
Since I always face xerces 1.6 and 1.4 crash at when parsing a file (most in
DOMStringHandle::operator new) and sometime in DOMString::transcode, I have
modified the ThreadTest.cpp and make threaMain just run below function
void testDOMStr(char* str)
{
DOMString domStr(str);
char* out
gzilla/show_bug.cgi?id=1650
DOMString error on LINUX
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Reso
onst toFill,
const unsigned int maxChars)
called like:
DOMString somestring;
//...
char buff[MAX_LEN];
XMLString::transcode( somestring.rawBuffer(), buff, MAX_LEN );
Here the second parameter is a preassigned buffer. The only draw back is
that
Yes, return=release.
I can't speak for everyone, but when I upgraded the BCB Xerces library, I
intentionally made it dependent upon the BCB c-rtl (cc3250mt.dll) so that
the application and the library could use a common memory manager, until
such time that Xerces implements a solution to the p
Tobias McNulty wrote:
>
> Thanks for the quick reply. [In the last paragraph,] by return do
> you mean release? If so, I'm curious as to how one is supposed to
> deal with this Xerces-allocated memory, if normal system functions do
> not work.
Normal system functions do work, as long as you use
cc: John Capehart
<[EMAIL PROTECTED]>,
[EMAIL PROTECTED], (bcc: David N
Bertoni/CAM/Lotus)
12/28/2001 02:00 Subject: DOMString
Hi Don,
Thanks for the quick reply. [In the last paragraph,] by return do
you mean release? If so, I'm curious as to how one is supposed to
deal with this Xerces-allocated memory, if normal system functions do
not work.
Thanks,
Toby
>Sounds like a heap collision between different memory m
ledge, Xerces has not implemented a function through
which you can return memory that was allocated by Xerces.
HTH,
Don
At 02:00 PM 12/28/2001 -0500, you wrote:
>Is there anything special about the char * returned by
>DOMString::transcode? I am using DOMString in JNI (which is probably pa
Is there anything special about the char * returned by
DOMString::transcode? I am using DOMString in JNI (which is probably
part of the problem) -- but I am getting some fairly abnormal
behavior. I am wondering if there is anything in particular I have
to do to dispose of the pointer
> I have a question about the DOMString class. I am writing a
> JNI-based library to access Xerces-J DOMs from C++. In looking for a
> decent string class to pass data around my wrapper classes, I came
> across Xerces-C's DOMString class.
Just out of curiosity why not use X
The FAQ http://xml.apache.org/xerces-c/faq-parse.html#faq-6 is some help
here. Quoting:
DOMStrings allow multiple concurrent readers. All DOMString const methods
are thread safe, and can be concurrently entered by multiple threads.
Non-const DOMString methods, such as appendData(), are not
tten it to run successfully yet --
>but my next problem doesn't seem to be directly related to
>DOMString. Is there anything else I might be missing that could be
>breaking something at another point in my library (e.g. somehow
>upsetting memory).
>
>Thanks,
>
>Toby
-
alling that when my library loads; it has fixed my
previous problem. I haven't gotten it to run successfully yet -- but
my next problem doesn't seem to be directly related to DOMString. Is
there anything else I might be missing that could be breaking
something at another point in my
I suspect you haven't called XMLPlatformUtils::Initialize.
-Original Message-
From: Tobias McNulty [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 06, 2001 10:35 AM
To: [EMAIL PROTECTED]
Subject: RE: DOMString class
Doug,
I apologize, that was an error in my e-mail. It s
Doug,
I apologize, that was an error in my e-mail. It should have read:
DOMString* myStr = new DOMString("foo");
as you also stated in your e-mail. That is what the actual code I
was compiling looked like.
I do delete the pointer later on in my code, but that is not the
point.
Tobias,
In C++, the new operator returns a pointer to the newly created object. So
at first glance, your code should be modified to read:
DOMString* pMyStr = new DOMString("foo");
Later in your code, before pMyStr goes out of scope, you should call
delete pMyStr;
to release
Hello!
I have a question about the DOMString class. I am writing a
JNI-based library to access Xerces-J DOMs from C++. In looking for a
decent string class to pass data around my wrapper classes, I came
across Xerces-C's DOMString class.
I tried linking to the xerces-c stub librar
gzilla/show_bug.cgi?id=1650
DOMString error on LINUX
--- Additional Comments From [EMAIL PROTECTED] 2001-12-03 01:54 ---
In ::calcRequiredSize() you are using mbstowcs(). The problem is that on Linux
Debian 2.2 R2 if the string contains a latin character (i.e. "Ñ", "ñ"
gzilla/show_bug.cgi?id=1650
DOMString error on LINUX
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|CLOSED |REOPENED
Resolution|DUP
gzilla/show_bug.cgi?id=1601
DOMString bug
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|CLOSED |REOPENED
Resolution
gzilla/show_bug.cgi?id=2014
"user breakpoint called" when deleting char strings created from transcode method off
of DOMString
[EMAIL PROTECTED] changed:
What|Removed |Added
gzilla/show_bug.cgi?id=4817
Can't free memory allocated by DOMString::transcode
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW
gzilla/show_bug.cgi?id=4817
Can't free memory allocated by DOMString::transcode
Summary: Can't free memory allocated by DOMString::transcode
Product: Xerces-C++
Version: 1.4
Platform: Other
OS/Version: Windows NT/2K
Status: NEW
Check the FAQ. You are mixing runtimes.
-Original Message-
From: nacho [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 09, 2001 11:53 AM
To: XERCES C list
Subject: problem with DOMString::transcode
Hi,
I'm having a problem while using this method in a little
example I wrote in
ssertion Exception
in dbgheap.c in _CrtIsValidHeapPointer(pUserData).
This function is called from free() which in turn is called from
delete().
The name of the function suggests that s is not a valid heap
pointer right? How can this be possible? I examined the
DOMString::transcode() code an
gzilla/show_bug.cgi?id=2879
Memory-Leak in DOMString-Class
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|
gzilla/show_bug.cgi?id=2032
DOMString or DOMNode Memory Leak when DTD is present
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|
gzilla/show_bug.cgi?id=1650
DOMString error on LINUX
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|
gzilla/show_bug.cgi?id=1601
DOMString bug
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|
gzilla/show_bug.cgi?id=1262
Can't delete the pointer returned by DOMString::transcode()
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED
erformance. We eventually hit a
wall with general memory allocation. We decided to link with smartheap and
found we were scaling much better.
I decided a radical idea...remove the local new and delete on DOMString and
let smartheap handle all allocations. This ended up working _almost_ as
good
gzilla/show_bug.cgi?id=3764
Memory allocation problem in DOMString class
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Reso
gzilla/show_bug.cgi?id=3764
Memory allocation problem in DOMString class
Summary: Memory allocation problem in DOMString class
Product: Xerces-C++
Version: 1.5.1
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity:
=3505
*** shadow/3505 Fri Sep 7 12:32:57 2001
--- shadow/3505.tmp.373 Fri Sep 7 12:32:57 2001
***
*** 0
--- 1,24
+ ++
+ | DOMString::transcode does not always detect wcstombs errors
> > Besides, why the profusion of operator == and
> operator !=? Isn't it
> > enough with one of them?
>
> There's a Standard C++ Library header that generates some operator
> overloads in terms of others, but I can't remember the name.
> Anway, it's
> almost certainly not available on
>>> Why is there bool operator== (const string& str_)const
>> Are you sure that there is? I thought that there was no use of
>> std::string in Xerces-C? In the DOMString class?
>Sorry, it should have said why _isn't_ there
Seems like this has been al
Murray Cumming wrote:
>
> "J. J. Merelo" wrote:
> >
> > Hi,
> > Why is there bool
> > operator== (const string& str_)const
>
> Are you sure that there is? I thought that there was no use of
> std::stri
"J. J. Merelo" wrote:
>
> Hi,
> Why is there bool
> operator== (const string& str_)const
Are you sure that there is? I thought that there was no use of
std::string in Xerces-C? In the DOMString class?
>
> I agree that
Hi,
Why is there bool
operator== (const string& str_)const
I agree that strings can be easily converted to char* ; but it
would make things much easier.
Besides, why the profusion of operator == and operator !=? Isn't it
enough
! AssignedTo: [EMAIL PROTECTED]
! ReportedBy: [EMAIL PROTECTED]
! URL:
! Summary: DOMString error on LINUX
!
I think my problem is the same as bug number: 1601
I read an XML with DOMParser. This xml contains an element with a character
entity &#
=1601
*** shadow/1601 Wed Jun 27 15:31:05 2001
--- shadow/1601.tmp.8510Wed Aug 8 13:37:38 2001
***
*** 1,7
++
| DOMString bug
=2879
*** shadow/2879 Mon Jul 30 01:50:36 2001
--- shadow/2879.tmp.22245 Mon Jul 30 05:05:54 2001
***
*** 2,9
| Memory-Leak in DOMString-Class
=2879
*** shadow/2879 Mon Jul 30 01:50:36 2001
--- shadow/2879.tmp.20083 Mon Jul 30 01:50:36 2001
***
*** 0
--- 1,64
+ ++
+ | Memory-Leak in DOMString-Class
See http://xml.apache.org/xerces-c/faq-parse.html#faq-26.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
do
something such as:
DOMString str("hello");
delete [] str.transcode();
then in debug mode with debug heap traces enabled, a breakpoint is called
from _CrtIsValidHeapPointer() in DGBHEAP.C and the following error is
output:
HEAP[xhcmc-debug.exe]: Invalid Address specified to Rt
:
! Severity: Blocker
! Priority: High
! Component: DOM
! AssignedTo: [EMAIL PROTECTED]
! ReportedBy: [EMAIL PROTECTED]
! URL:
! Cc:
! Summary: DOMString bug
!
On linux slackware 7.1 kernel 2.4.4
gcc version :2.95.2
platform :i686
--- 1,19
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2119
*** shadow/2119 Mon Jun 11 09:25:58 2001
--- shadow/2119.tmp.9436Thu Jun 21 06:21:33 2001
***
*** 7,13
| Severity: Enhancement OS/Version: All |
| Priority: Other
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2119
*** shadow/2119 Mon Jun 11 09:25:58 2001
--- shadow/2119.tmp.29391 Mon Jun 11 09:25:58 2001
***
*** 0
--- 1,19
+ ++
+ | DOMString::print
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2014
*** shadow/2014 Wed Jun 6 09:38:41 2001
--- shadow/2014.tmp.21762 Fri Jun 8 13:34:31 2001
***
*** 41,43
--- 41,49
Debug Error!
Damage: after normal block (#531) at "hex address"
+
+ --- Additional Com
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2032
*** shadow/2032 Wed Jun 6 14:09:02 2001
--- shadow/2032.tmp.12112 Wed Jun 6 14:11:08 2001
***
*** 5,11
| Status: NEW Version: 1.4 |
| Resolution:
1 - 100 of 131 matches
Mail list logo
