/XERCESC-1206
Here is an overview of the issue:
-
Key: XERCESC-1206
Summary: IconvGNU transcoder returns char arrays starting with \0
Type: Bug
Status: Resolved
Priority: Major
Resolution: FIXED
This seems like an obvious question, but I haven't been able to find
much about in the documentation, FAQs, or mailing list archives.
For GNU/Linux, why would one choose the iconvGNU transcoder over the
native transcoder or the other way around?
I'm maintaining the Debian GNU/Linu
:
-
Key: XERCESC-1206
Summary: IconvGNU transcoder returns char arrays starting with \0
Type: Bug
Status: Unassigned
Priority: Major
Project: Xerces-C++
Components:
Utilities
Versions:
2.5.0
Assignee:
Reporter: HAUTION Philippe
PROTECTED]
CC: [EMAIL PROTECTED]
Subject: Re: Transcoder
Date: Tue, 03 Feb 2004 19:46:26 +0100
MIME-Version: 1.0
X-Sender: [EMAIL PROTECTED]
Received: from mail.apache.org ([208.185.179.12]) by mc8-f15.hotmail.com
with Microsoft SMTPSVC(5.0.2195.6824); Tue, 3 Feb 2004 10:47:33 -0800
Received: (qm
p;m=101967701624711&w=2
Any pointers as to where I could start to achieve this ? I am assuming I
should look closely at Transservice.hpp but I'd rather start with good
advice than just jumping into it.
Even if the transcoder you are using does support computing the source
offset
Hello!
I am trying to use the SAX2XMLReader::getSrcOffset() function on my windows
2K machine and I get a runtime exception with the following message:
"Message: An exception occurred! Type:RuntimeException, Message:The
current transcoding
service does not support source offset informatio
t;'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
|
| cc:
|
| Subject: 124
12436 - UTF-8 transcoder is not strict (and therefore not secure).
Xerces 2.3.0 fixed bug #12436, unfortunately my company has shipped some XML
files that do not conform to this. (The trade-mark symbol) So newer code
that uses version 2.3.0 cannot parse these older files. Is there a way for
me
gzilla/show_bug.cgi?id=12436
UTF-8 transcoder is not strict (and therefore not secure).
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|ASSIGNED|RE
gzilla/show_bug.cgi?id=12436
UTF-8 transcoder is not strict (and therefore not secure).
--- Additional Comments From [EMAIL PROTECTED] 2003-03-20 18:44 ---
This fix was designed to be as performant as possible. Nonetheless, for
documents extensively using multibyte UTF8 sequences, there
gzilla/show_bug.cgi?id=12436
UTF-8 transcoder is not strict (and therefore not secure).
--- Additional Comments From [EMAIL PROTECTED] 2003-03-20 18:42 ---
Created an attachment (id=5452)
patch fixing bug with a new error m
gzilla/show_bug.cgi?id=12436
UTF-8 transcoder is not strict (and therefore not secure).
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |AS
Colin,
Would you please open a bug report at bugzilla? thanks.
Rgds,
PeiYong
- Original Message -
From: "Colin Paul Adams" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, February 01, 2003 11:23 AM
Subject: Transcoder block size
> In the con
In the constructors for transcoders, such as XMLUTF8Transcoder, there
is a block size parameter. According to the comments in the header
file, this parameter limits the maximum size of data that can be
converted by one call to transcodeFrom or transcodeTo. My experience
(with the latest nightly bui
gzilla/show_bug.cgi?id=1687
resValue not always updated when making a transcoder
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|
gzilla/show_bug.cgi?id=8289
transcoder map is not thread safe on SMP machines
[EMAIL PROTECTED] changed:
What|Removed |Added
URL||http://xml.apac
gzilla/show_bug.cgi?id=8289
transcoder map is not thread safe on SMP machines
Summary: transcoder map is not thread safe on SMP machines
Product: Xerces-C++
Version: 1.7.0
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Se
gzilla/show_bug.cgi?id=7763
final memory cleanup for ICU transcoder
Summary: final memory cleanup for ICU transcoder
Product: Xerces-C++
Version: 1.7.0
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority:
Subject: final memory cleanup for ICU transcoder
> Hello people,
>
> There is a small piece of code utilizing lazily allocated data clean-up
> appeared in last versions of ICU library. Although it is not a vital
> improvement I hope this helps to fight actual memory leaks.
>
>
>
Hello people,
There is a small piece of code utilizing lazily allocated data clean-up
appeared in last versions of ICU library. Although it is not a vital
improvement I hope this helps to fight actual memory leaks.
Index: xerces_1_7/src/xercesc/util/Transcoders/ICU/ICUTransService.cpp
diff -c x
gzilla/show_bug.cgi?id=1687
resValue not always updated when making a transcoder
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RE
gzilla/show_bug.cgi?id=1687
resValue not always updated when making a transcoder
--- Additional Comments From [EMAIL PROTECTED] 2002-03-12 19:09 ---
Mark,
Your patch is in the CVS, please help verify and close the bug, thanks.
Rgds,
P
My understanding now is that the standard specification for wcstombs does
not dictate that if a buffer size of zero is passed in, the size needed
should be returned. This seems only to be a (documented) side effect of the
implementation in VC++ and Borland. It also doesn't dictate that the
wchar_t
Goeff and Dean,
After looking at the C RTL sources for both Borland and MSVC, wcstombs()
returns -1 on errors using either compiler. The Borland documentation
states "If an invalid multibyte character is encountered, wcstombs returns
(size_t) -1. Otherwise, the function returns the number of
On 9/28/01 12:50 AM, "Dean Roddey" <[EMAIL PROTECTED]> wrote:
> No, definitely not 2 bytes. UTF-8 can take up to 6 bytes to hold a single
> Unicode character, and others can take 3 or 4 and whatnot. You really need
> to know what the target is going to take. And you can't really afford to do
> a
> At any rate, it should be safe to modify Win32LCPTranscoder::transcode()
to
> simply allocate 2 bytes per unicode character before transcoding,
shouldn't
> it?
>
No, definitely not 2 bytes. UTF-8 can take up to 6 bytes to hold a single
Unicode character, and others can take 3 or 4 and whatnot.
My apologies for the hasty postit's late :)
In looking a little more, it looks like wcstombs is not _supposed_ to return
the needed size when the buffer pointer is null, although MSDN documents it
this way, so I assume it does work this way in MSVC++??
But in every other reference, I see no
Ok, thanks to those who addressed my previous questions. I have one more
question, this time on the windows side.
Our windows work was done on Windows 2000, and everything worked well. But
we received reports from testers that it was not working on Windows 98. In
digging through it, I see that th
l Message -
From: "Geoff Coffey" <[EMAIL PROTECTED]>
To: "xerces c dev" <[EMAIL PROTECTED]>
Sent: Wednesday, September 26, 2001 11:02 PM
Subject: Transcoder::canTranscodeTo behavior
> We're using xerces on Mac OS and the implementation of
> MacOSTr
We're using xerces on Mac OS and the implementation of
MacOSTranscoder::canTranscodeTo() needs some work. Right now it simply
returns true in all cases, which is obviously not a good thing.
I've modified the implementation and it is working well, but there is
something I don't understand. The Win
) whereas XML256TableTranscoder replaces them with
0x3f ('?') and XMLUTF8Transcoder replaces with chSpace. This seems
inconsistent... ideally there should be a way to specify the character used
or at least a way to query a transcoder to find its default value.
Currently the values are m
med that ucnv_close() ran
in XMLPlatformUtils::Terminate().
It isn't enough only ucnv_close()?
Thanks, Yoriko Nakata.
- Original Message -
From: "Yoriko Nakata" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 13, 2001 9:56 AM
Subject: ICU transcod
Hello,
I use ICUTranscoder to support "Shift-JIS" & "EUC-JP" encode.
My program delete target buffer(it is setted local code data) and crash. If
it transcode from UNICODE to local encoding,
It doesn't crash ,if it transcode from UNICODE to UTF-8 or UTF-16 that
Xerces suppoting encode.
I'm using X
always updated when making a transcoder |
+ ++
+ |Bug #: 1687Product: Xerces-C|
+ | Status: NEW Version: 1.4
Dean wrote:
> I'm not sure how many platforms that worst case scenario happens on, but
it
> could happen. Linux would probably be one, since it has a 32 bit wchar_t
and
> so its Iconv probably uses UCS-4 format.
iconv converts between two named encodings, so it can easily convert
directly from w
ne you are
using. Basically, you call the XMLPlatformUtils::fgTransService object and
ask it to create a transcoder for you. It will create one, using whatever
transcoding service is plugged into the parser on that platform, and return
it to you via the base XMLTranscoder interface.
This allows yo
wchar_t and get a XMLCh back without
loosing the Unicode first by converting to char*? I'm probably just not
making a connection on this one.
4. IconvTranscoder doesn't define the transcodeTo & transcodeFrom that are
found in its base class so this doesn't seem like a va
37 matches
Mail list logo
