Re: [Mono-dev] String.Compare bug

2011-04-14 Thread Nicklas Overgaard
Hi,

It's now filed as bug #687444

/Nicklas

On Wed, 2011-04-13 at 17:56 -0300, Rodrigo Kumpera wrote:
 Please file a bug report so this bug isn't forgotten.
 
 On Wed, Apr 13, 2011 at 3:52 PM, Nicklas Overgaard nick...@isharp.dk
 wrote:
 Hi again,
 
 The previously attached patch does not apply for some reason.
 A new one
 is attached here.
 
 Sorry about that.
 
 /Nicklas
 
 
 On Wed, 2011-04-13 at 18:05 +0200, Nicklas Overgaard wrote:
  Hi mono devers!
 
  I discovered a bug in String.Compare when using a UTF8
 string created
  from a byte array with a zero-byte at the end. It's
 converted to the
  same string on both .net and mono, however, String.Compare
 on .net is
  different from String.Compare on mono.
 
  The issue is the following:
 
  Mono reports 1 on the string compare, signaling that the
 converted
  string is larger than the hard-coded string I compare it
 to. And it
  kinda is - the byte array is converted to %EOF\0 and the
 hardcoded
  string is just %EOF - but .net manages to ignore the '\0'
 when doing
  the compare, which results in 0 (equal strings).
 
  Attached is a patch, which adds a test-case to
  'mcs/class/corlib/Test/System' which shows the issue -
  CompareNotWorking3 to follow the lingo :)
 
  I have tried to track the issue down myself in
 String.Compare, but I
  gave up due to the complexity of the underlying code.
 
  As a final note, I'm running with UTF8 culture on my Linux
 box, where
  the issue is showing up.
 
  Best regards,
 
  Nicklas Overgaard
 
 
 
  ___
  Mono-devel-list mailing list
  Mono-devel-list@lists.ximian.com
  http://lists.ximian.com/mailman/listinfo/mono-devel-list
 
 
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list
 
 
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: [Mono-dev] String.Compare bug

2011-04-14 Thread Atsushi Eno
It is now fixed in git. If you would like to see what's inside the sausage:
https://github.com/mono/mono/commit/8277f4a

NET is too inconsistent on how to process \0 in Compare(), IndexOf() 
and LastIndexOf(). IMO We should totally switch to .NET 4's strategy to 
eliminate
extraneous misuse of CompareInfo.

Atsushi Eno

(2011/04/14 16:02), Nicklas Overgaard wrote:
 Hi,

 It's now filed as bug #687444

 /Nicklas

 On Wed, 2011-04-13 at 17:56 -0300, Rodrigo Kumpera wrote:
 Please file a bug report so this bug isn't forgotten.

 On Wed, Apr 13, 2011 at 3:52 PM, Nicklas Overgaardnick...@isharp.dk
 wrote:
  Hi again,

  The previously attached patch does not apply for some reason.
  A new one
  is attached here.

  Sorry about that.

  /Nicklas


  On Wed, 2011-04-13 at 18:05 +0200, Nicklas Overgaard wrote:
Hi mono devers!
  
I discovered a bug in String.Compare when using a UTF8
  string created
from a byte array with a zero-byte at the end. It's
  converted to the
same string on both .net and mono, however, String.Compare
  on .net is
different from String.Compare on mono.
  
The issue is the following:
  
Mono reports 1 on the string compare, signaling that the
  converted
string is larger than the hard-coded string I compare it
  to. And it
kinda is - the byte array is converted to %EOF\0 and the
  hardcoded
string is just %EOF - but .net manages to ignore the '\0'
  when doing
the compare, which results in 0 (equal strings).
  
Attached is a patch, which adds a test-case to
'mcs/class/corlib/Test/System' which shows the issue -
CompareNotWorking3 to follow the lingo :)
  
I have tried to track the issue down myself in
  String.Compare, but I
gave up due to the complexity of the underlying code.
  
As a final note, I'm running with UTF8 culture on my Linux
  box, where
the issue is showing up.
  
Best regards,
  
Nicklas Overgaard
  
  

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


  ___
  Mono-devel-list mailing list
  Mono-devel-list@lists.ximian.com
  http://lists.ximian.com/mailman/listinfo/mono-devel-list


 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list




___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


[Mono-dev] String.Compare bug

2011-04-13 Thread Nicklas Overgaard
Hi mono devers!

I discovered a bug in String.Compare when using a UTF8 string created
from a byte array with a zero-byte at the end. It's converted to the
same string on both .net and mono, however, String.Compare on .net is
different from String.Compare on mono.

The issue is the following:

Mono reports 1 on the string compare, signaling that the converted
string is larger than the hard-coded string I compare it to. And it
kinda is - the byte array is converted to %EOF\0 and the hardcoded
string is just %EOF - but .net manages to ignore the '\0' when doing
the compare, which results in 0 (equal strings).

Attached is a patch, which adds a test-case to
'mcs/class/corlib/Test/System' which shows the issue -
CompareNotWorking3 to follow the lingo :)

I have tried to track the issue down myself in String.Compare, but I
gave up due to the complexity of the underlying code.

As a final note, I'm running with UTF8 culture on my Linux box, where
the issue is showing up.

Best regards,

Nicklas Overgaard


diff --git a/mcs/class/corlib/Test/System/StringTest.cs b/mcs/class/corlib/Test/System/StringTest.cs
index 033f81d..9909cf0 100644
--- a/mcs/class/corlib/Test/System/StringTest.cs
+++ b/mcs/class/corlib/Test/System/StringTest.cs
@@ -578,6 +578,21 @@ public class StringTest
}
}
}
+   
+   [Test]
+   public void CompareNotWorking3()
+   {
+   byte [] theBytes = new byte[5] {37,  69, 79, 70, 0};
+   
+   // Windows Server 2008 and Mono 2.10.1 returns
+   // '%EOF\0'
+   string theStr = Encoding.UTF8.GetString(theBytes, 0, 5);
+   
+   // the string we wish to find
+   string theRealStr = %EOF;
+   
+   Assert.AreEqual(0, string.Compare(theStr, theRealStr), .NET returns 0);
+   }
 
[Test]
public void Compare ()

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: [Mono-dev] String.Compare bug

2011-04-13 Thread Nicklas Overgaard
Hi again,

The previously attached patch does not apply for some reason. A new one
is attached here.

Sorry about that.

/Nicklas

On Wed, 2011-04-13 at 18:05 +0200, Nicklas Overgaard wrote:
 Hi mono devers!
 
 I discovered a bug in String.Compare when using a UTF8 string created
 from a byte array with a zero-byte at the end. It's converted to the
 same string on both .net and mono, however, String.Compare on .net is
 different from String.Compare on mono.
 
 The issue is the following:
 
 Mono reports 1 on the string compare, signaling that the converted
 string is larger than the hard-coded string I compare it to. And it
 kinda is - the byte array is converted to %EOF\0 and the hardcoded
 string is just %EOF - but .net manages to ignore the '\0' when doing
 the compare, which results in 0 (equal strings).
 
 Attached is a patch, which adds a test-case to
 'mcs/class/corlib/Test/System' which shows the issue -
 CompareNotWorking3 to follow the lingo :)
 
 I have tried to track the issue down myself in String.Compare, but I
 gave up due to the complexity of the underlying code.
 
 As a final note, I'm running with UTF8 culture on my Linux box, where
 the issue is showing up.
 
 Best regards,
 
 Nicklas Overgaard
 
 
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list

diff --git a/mcs/class/corlib/Test/System/StringTest.cs b/mcs/class/corlib/Test/System/StringTest.cs
index 033f81d..97d30e1 100644
--- a/mcs/class/corlib/Test/System/StringTest.cs
+++ b/mcs/class/corlib/Test/System/StringTest.cs
@@ -579,6 +579,21 @@ public class StringTest
 		}
 	}
 
+   [Test]
+   public void CompareNotWorking3()
+   {
+		byte [] theBytes = new byte[5] {37,  69, 79, 70, 0};
+		   
+		// Windows Server 2008 and Mono 2.10.1 returns
+		// '%EOF\0'
+		string theStr = Encoding.UTF8.GetString(theBytes, 0, 5);
+
+		// the string we wish to find
+		string theRealStr = %EOF;
+   
+		Assert.AreEqual(0, string.Compare(theStr, theRealStr), .NET returns 0);
+	}
+ 
 	[Test]
 	public void Compare ()
 	{
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: [Mono-dev] String.Compare bug

2011-04-13 Thread Rodrigo Kumpera
Please file a bug report so this bug isn't forgotten.

On Wed, Apr 13, 2011 at 3:52 PM, Nicklas Overgaard nick...@isharp.dkwrote:

 Hi again,

 The previously attached patch does not apply for some reason. A new one
 is attached here.

 Sorry about that.

 /Nicklas

 On Wed, 2011-04-13 at 18:05 +0200, Nicklas Overgaard wrote:
  Hi mono devers!
 
  I discovered a bug in String.Compare when using a UTF8 string created
  from a byte array with a zero-byte at the end. It's converted to the
  same string on both .net and mono, however, String.Compare on .net is
  different from String.Compare on mono.
 
  The issue is the following:
 
  Mono reports 1 on the string compare, signaling that the converted
  string is larger than the hard-coded string I compare it to. And it
  kinda is - the byte array is converted to %EOF\0 and the hardcoded
  string is just %EOF - but .net manages to ignore the '\0' when doing
  the compare, which results in 0 (equal strings).
 
  Attached is a patch, which adds a test-case to
  'mcs/class/corlib/Test/System' which shows the issue -
  CompareNotWorking3 to follow the lingo :)
 
  I have tried to track the issue down myself in String.Compare, but I
  gave up due to the complexity of the underlying code.
 
  As a final note, I'm running with UTF8 culture on my Linux box, where
  the issue is showing up.
 
  Best regards,
 
  Nicklas Overgaard
 
 
  ___
  Mono-devel-list mailing list
  Mono-devel-list@lists.ximian.com
  http://lists.ximian.com/mailman/listinfo/mono-devel-list


 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list