Hi,
On Thu, 2002-08-15 at 18:02, Benenati, ChrisX J wrote:
> Seems to fix the problem
Thanks for testing. I have created a Mauve test so I could reproduce it
with Kissme and checked in this fix.
2002-08-15 Mark Wielaard <[EMAIL PROTECTED]>
* gnu/java/io/encode/Encoder.java (convertToBytes
Seems to fix the problem
> -Original Message-
> From: Mark Wielaard [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, August 14, 2002 1:36 PM
> To: Benenati, ChrisX J
> Cc: '[EMAIL PROTECTED]'
> Subject: Re: Bug(s) in java.lang.String
>
>
> Hi,
>
&g
Hi,
On Wed, Aug 14, 2002 at 01:10:00PM -0700, Benenati, ChrisX J wrote:
> There seems to be a related problem with getBytes(String enc) and
> getBytes().
>
> Running under ORP, these methods are returning all of the trailing nul bytes
> as well as the valid characters in the String.
This seems
There seems to be a related problem with getBytes(String enc) and
getBytes().
Running under ORP, these methods are returning all of the trailing nul bytes
as well as the valid characters in the String.
Unfortunately, the code I'm running is part of a huge mass of code belonging
to someone else,
Hi,
On Tue, 2002-08-13 at 16:19, Stephen Crawley wrote:
> The patch works for Kissme.
Thanks for testing. I have committed it to CVS now.
2002-08-13 Mark Wielaard <[EMAIL PROTECTED]>
* java/lang/Character.java (zeroBasedStringValue): New method.
(blocks): Use zeroBasedStringValue().
[EMAIL PROTECTED] said:
> Yeah. It seems to be legal for a VM to do tricks like this. Eric Blake
> suggested to just use System.arraycopy to make sure that the array is
> always zero based. The attached patch does that when the char[] is not
> already zero based. I have not yet tested it. Could y
Mark Wielaard wrote:
> Another solution would be to encode the values in CharData not as
> Strings but as actual char[] but that might be a lot less efficient
> (source code may explode I mean, it shouldn't matter for the class
> file).
Just the opposite IMHO. Source would be not longer, at
Hi,
On Fri, 2002-08-09 at 17:48, Stephen Crawley wrote:
> I've finally found time to track down the cause of this bug. It turns out
> that it is a consequence of the way that Kissme unpacks "asciz" strings
> with multi-byte characters. In this case Kissme is creating a String object
> with cou
Folks,
I've finally found time to track down the cause of this bug. It turns out
that it is a consequence of the way that Kissme unpacks "asciz" strings
with multi-byte characters. In this case Kissme is creating a String object
with count == 204, offset == 0, value.length == 443, and the val
On 31 Jul 2002, Mark Wielaard wrote:
> I am still interested in how/why those Strings had a non-zero offset in
> the first place. Maybe a compiler/VM may do such a thing and then we
> have to take that into account in Character and String when we use them.
The bytecode compiler cannot do this, b
Hi,
On Wed, 2002-07-31 at 23:14, Artur Biesiadowski wrote:
> Mark Wielaard wrote:
>
> > Another solution would be to encode the values in CharData not as
> > Strings but as actual char[] but that might be a lot less efficient
> > (source code may explode I mean, it shouldn't matter for the cl
Hi,
On Wed, 2002-07-31 at 17:57, Stephen Crawley wrote:
> the Kissme VM goes into an infinite loop. The problem is in the private
> "upperCaseIndex" method that performs a binary search of a table encoded
> as a char array represented by the String value CharData.UPPER_SPECIAL.
> The problem is
I've found a bug in the Classpath java.lang.String implementation that
shows up on Kissme. It happens in the Mauve test-case:
gnu.testlet.java.lang.String.CASE_INSENSITIVE_ORDER
When the testcase calls:
String.CASE_INSENSITIVE_ORDER.compare("\u00df", "sS");
the Kissme VM goes into an inf
13 matches
Mail list logo
