Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > False Positives From String Comparison using string.Equals()

Reply
Thread Tools

False Positives From String Comparison using string.Equals()

 
 
Smithers
Guest
Posts: n/a
 
      06-20-2009
I am using the .Equals() method of the string class, as follows, to compare
string properties of two different instances of a given class.


if
(!valuesFromUI.Other_Description.Equals(valuesAsRe trievedFromDB.Other_Description,
StringComparison.OrdinalIgnoreCase))
{
return true;
}

What I am observing in testing is that the above .Equals() periodically
finds that the string values are different when they do not in fact appear
to be different in any way. By "appear to be different in any way" I mean
that I hover the mouse over each property and view in the "Text Visualizer",
then copy from there into Notepad and compare the values in notepad - they
appear to be the exact same string.

The bigger picture is this: I'm using Visual Studio Pro 2008. This is
happening in an ASP.NET Web application. I instantiate the class and
populate it with values from the underlying SQL Server 2005 database, then
load those properties into the UI, and then store the object instance in a
Session variable. Then, when the user navigates to a different page, I
instantiate a new instance of the class and populate it with values from the
UI. I then compare relevant properties of that instance - as in the sample
code above - against the same properties from the instance that was
previously stored in Session state. I do this to determine if the user
actually modified any values from the underlying database and therefore
whether to save any changes to the database.

How can I compare the strings in a way that would not result in such "false
positives"? I would think my approach, above, is perfectly fine. What can I
do differently?

Thanks.


 
Reply With Quote
 
 
 
 
Jeroen Mostert
Guest
Posts: n/a
 
      06-20-2009
Smithers wrote:
> I am using the .Equals() method of the string class, as follows, to compare
> string properties of two different instances of a given class.
>
>
> if
> (!valuesFromUI.Other_Description.Equals(valuesAsRe trievedFromDB.Other_Description,
> StringComparison.OrdinalIgnoreCase))
> {
> return true;
> }
>
> What I am observing in testing is that the above .Equals() periodically
> finds that the string values are different when they do not in fact appear
> to be different in any way. By "appear to be different in any way" I mean
> that I hover the mouse over each property and view in the "Text Visualizer",
> then copy from there into Notepad and compare the values in notepad - they
> appear to be the exact same string.
>

But are they? Your test is not definitive. Whitespace is not distinguishable
visually and there are plenty of visible characters who share glyphs.

For starters, compare the string *lengths*. If those are the same, go into
the immediate window and check if Encoding.UTF8.GetBytes() yields the same
result on both strings. If that's the case and the strings still don't
compare equal then you might've found a genuine bug in the framework, but
that's very unlikely.

> The bigger picture is this: I'm using Visual Studio Pro 2008. This is
> happening in an ASP.NET Web application. I instantiate the class and
> populate it with values from the underlying SQL Server 2005 database


If you're using CHAR fields (fixed length, whitespace padding,
encoding-specific) or VARCHAR fields (encoding-specific) as opposed to
NVARCHAR fields, this could be the cause of your strings not round-tripping.

--
J.
 
Reply With Quote
 
 
 
 
Cor Ligthert[MVP]
Guest
Posts: n/a
 
      06-21-2009
This is possible as the DataBase returns spaces.

However, simply testing (StringX == StringY) gives the same result and in my
opinion much easier then let it go trough an extra old derived C function.

Cor


"Smithers" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>I am using the .Equals() method of the string class, as follows, to compare
>string properties of two different instances of a given class.
>
>
> if
> (!valuesFromUI.Other_Description.Equals(valuesAsRe trievedFromDB.Other_Description,
> StringComparison.OrdinalIgnoreCase))
> {
> return true;
> }
>
> What I am observing in testing is that the above .Equals() periodically
> finds that the string values are different when they do not in fact appear
> to be different in any way. By "appear to be different in any way" I mean
> that I hover the mouse over each property and view in the "Text
> Visualizer", then copy from there into Notepad and compare the values in
> notepad - they appear to be the exact same string.
>
> The bigger picture is this: I'm using Visual Studio Pro 2008. This is
> happening in an ASP.NET Web application. I instantiate the class and
> populate it with values from the underlying SQL Server 2005 database, then
> load those properties into the UI, and then store the object instance in a
> Session variable. Then, when the user navigates to a different page, I
> instantiate a new instance of the class and populate it with values from
> the UI. I then compare relevant properties of that instance - as in the
> sample code above - against the same properties from the instance that was
> previously stored in Session state. I do this to determine if the user
> actually modified any values from the underlying database and therefore
> whether to save any changes to the database.
>
> How can I compare the strings in a way that would not result in such
> "false positives"? I would think my approach, above, is perfectly fine.
> What can I do differently?
>
> Thanks.
>


 
Reply With Quote
 
Jeroen Mostert
Guest
Posts: n/a
 
      06-21-2009
Cor Ligthert[MVP] wrote:
> "Smithers" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> I am using the .Equals() method of the string class, as follows, to
>> compare string properties of two different instances of a given class.
>>
>>
>> if
>> (!valuesFromUI.Other_Description.Equals(valuesAsRe trievedFromDB.Other_Description,
>> StringComparison.OrdinalIgnoreCase))
>> {
>> return true;
>> }
>>

<snip>
> However, simply testing (StringX == StringY) gives the same result


That's equivalent to an ordinal comparison, not a case-insensitive ordinal
comparison like the OP is using.

--
J.
 
Reply With Quote
 
Hans Kesting
Guest
Posts: n/a
 
      06-22-2009

It happens that Cor Ligthert[MVP] formulated :
> This is possible as the DataBase returns spaces.
>
> However, simply testing (StringX == StringY) gives the same result and in my
> opinion much easier then let it go trough an extra old derived C function.
>
> Cor
>


No, that would not give the same results.
"A" == "a" would return false,
"A".Equals("a", StringComparison.OrdinalIgnoreCase) would return true.

You are right however to point to the possibility of extra spaces in
the "database" value. They would not be visible but would mess up the
comparison.
As a hint to the OP: that's why I don't just "Console.WriteLine" those
strings, but add some sort of brackets around them:
Console.WriteLine("[" + stringToDisplay + "]");
Then extra spaces would become apparent.

Hans Kesting

>
> "Smithers" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>>I am using the .Equals() method of the string class, as follows, to compare
>> string properties of two different instances of a given class.
>>
>>
>> if
>> (!valuesFromUI.Other_Description.Equals(valuesAsRe trievedFromDB.Other_Description,
>> StringComparison.OrdinalIgnoreCase))
>> {
>> return true;
>> }
>>
>> What I am observing in testing is that the above .Equals() periodically
>> finds that the string values are different when they do not in fact appear
>> to be different in any way. By "appear to be different in any way" I mean
>> that I hover the mouse over each property and view in the "Text
>> Visualizer", then copy from there into Notepad and compare the values in
>> notepad - they appear to be the exact same string.
>>
>> The bigger picture is this: I'm using Visual Studio Pro 2008. This is
>> happening in an ASP.NET Web application. I instantiate the class and
>> populate it with values from the underlying SQL Server 2005 database, then
>> load those properties into the UI, and then store the object instance in a
>> Session variable. Then, when the user navigates to a different page, I
>> instantiate a new instance of the class and populate it with values from
>> the UI. I then compare relevant properties of that instance - as in the
>> sample code above - against the same properties from the instance that was
>> previously stored in Session state. I do this to determine if the user
>> actually modified any values from the underlying database and therefore
>> whether to save any changes to the database.
>>
>> How can I compare the strings in a way that would not result in such "false
>> positives"? I would think my approach, above, is perfectly fine. What can I
>> do differently?
>>
>> Thanks.
>>



 
Reply With Quote
 
Merk
Guest
Posts: n/a
 
      06-22-2009

<< SNIP>>


> As a hint to the OP: that's why I don't just "Console.WriteLine" those
> strings, but add some sort of brackets around them:
> Console.WriteLine("[" + stringToDisplay + "]");
> Then extra spaces would become apparent.



Upon reading from the DB and UI, each string is trimmed (theString.Trim()).
So, I think that would resolve any extra spaces issue.

I have yet to try the suggestion by Mr. Covington. That looks like it might
shed some light on the situation.

-S


 
Reply With Quote
 
Cor Ligthert[MVP]
Guest
Posts: n/a
 
      06-22-2009

Hans,

Most people here are clever enough that they know that it is possible to
write, I take mostly the shortest notation when I want to show something.

("A".ToUpper() == "a".ToUpper())

Cor

"Hans Kesting" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> It happens that Cor Ligthert[MVP] formulated :
>> This is possible as the DataBase returns spaces.
>>
>> However, simply testing (StringX == StringY) gives the same result and in
>> my opinion much easier then let it go trough an extra old derived C
>> function.
>>
>> Cor
>>

>
> No, that would not give the same results.
> "A" == "a" would return false,
> "A".Equals("a", StringComparison.OrdinalIgnoreCase) would return true.
>
> You are right however to point to the possibility of extra spaces in the
> "database" value. They would not be visible but would mess up the
> comparison.
> As a hint to the OP: that's why I don't just "Console.WriteLine" those
> strings, but add some sort of brackets around them:
> Console.WriteLine("[" + stringToDisplay + "]");
> Then extra spaces would become apparent.
>
> Hans Kesting
>
>>
>> "Smithers" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>>I am using the .Equals() method of the string class, as follows, to
>>>compare string properties of two different instances of a given class.
>>>
>>>
>>> if
>>> (!valuesFromUI.Other_Description.Equals(valuesAsRe trievedFromDB.Other_Description,
>>> StringComparison.OrdinalIgnoreCase))
>>> {
>>> return true;
>>> }
>>>
>>> What I am observing in testing is that the above .Equals() periodically
>>> finds that the string values are different when they do not in fact
>>> appear to be different in any way. By "appear to be different in any
>>> way" I mean that I hover the mouse over each property and view in the
>>> "Text Visualizer", then copy from there into Notepad and compare the
>>> values in notepad - they appear to be the exact same string.
>>>
>>> The bigger picture is this: I'm using Visual Studio Pro 2008. This is
>>> happening in an ASP.NET Web application. I instantiate the class and
>>> populate it with values from the underlying SQL Server 2005 database,
>>> then load those properties into the UI, and then store the object
>>> instance in a Session variable. Then, when the user navigates to a
>>> different page, I instantiate a new instance of the class and populate
>>> it with values from the UI. I then compare relevant properties of that
>>> instance - as in the sample code above - against the same properties
>>> from the instance that was previously stored in Session state. I do this
>>> to determine if the user actually modified any values from the
>>> underlying database and therefore whether to save any changes to the
>>> database.
>>>
>>> How can I compare the strings in a way that would not result in such
>>> "false positives"? I would think my approach, above, is perfectly fine.
>>> What can I do differently?
>>>
>>> Thanks.
>>>

>
>


 
Reply With Quote
 
Göran Andersson
Guest
Posts: n/a
 
      06-23-2009

Cor Ligthert[MVP] wrote:
> Hans,
>
> Most people here are clever enough that they know that it is possible to
> write, I take mostly the shortest notation when I want to show something.
>
> ("A".ToUpper() == "a".ToUpper())
>
> Cor
>


Why would you process the strings just to use one comparison, when there
is another comparison that does exactly what you want without first
processing the strings?

--
Göran Andersson
_____
http://www.guffa.com
 
Reply With Quote
 
Cor Ligthert[MVP]
Guest
Posts: n/a
 
      06-24-2009

Goran,

Most people are clever enough to know what is done behind the scene.

Strings to Upper doesn't process the string, it only takes a subset of the
ascii code, it does not work by instance with the Turkish uppercase i.

Cor


"Göran Andersson" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> Cor Ligthert[MVP] wrote:
>> Hans,
>>
>> Most people here are clever enough that they know that it is possible to
>> write, I take mostly the shortest notation when I want to show something.
>>
>> ("A".ToUpper() == "a".ToUpper())
>>
>> Cor
>>

>
> Why would you process the strings just to use one comparison, when there
> is another comparison that does exactly what you want without first
> processing the strings?
>
> --
> Göran Andersson
> _____
> http://www.guffa.com


 
Reply With Quote
 
Jeroen Mostert
Guest
Posts: n/a
 
      06-24-2009
Cor Ligthert[MVP] wrote:
> Most people are clever enough to know what is done behind the scene.
>

Those people shouldn't propagate techniques they should know are bad.

> Strings to Upper doesn't process the string,


What Göran meant is that .ToUpper() creates a new string, which is then
compared. Using .Equals() with a StringComparison saves you a string
creation (or two) because it compares character-by-character (and it skips
the comparison altogether if the lengths differ).

In short: never use .ToUpper() (or .ToLower()) to compare strings in a
case-insensitive manner. It's strictly worse than using .Equals() with the
appropriate StringComparison flag.

Yes, even if you think it doesn't look as nice. And even (or actually
*especially*) for demonstration code.

--
J.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Potential Software Conflicts and False Positives? Heidi Manway Computer Support 3 01-19-2007 10:54 PM
Valgrind errors: valid, or false positives ? Simple Simon C Programming 4 11-04-2006 04:16 PM
Spy Sweeper 4.5 - False Positives null Computer Security 1 11-08-2005 08:05 PM
Re: avg false positives ellis_jay Computer Support 0 08-10-2005 11:19 PM
Xtra spam filter -- false positives. Ralph Fox NZ Computing 14 07-05-2004 08:36 PM



Advertisments