- Classification: UNCLASSIFIED

>

I use that logic to determine if a value, regardless of type, can become a number type.

> if (a !== a) {

> }

>

> if (a === a) {

> }

>

For instance:

a = "4";

if (Number(a) === Number(a)) // true

b "4a";

if (Number(b) === Number(b)) // false, because NaN does not equal NaN as they are type number, but are not a valid number.

Further more you could have a comparison of functions where a number type is returned:

a = function (x) {

return (Number(x) + 3);

}

if (a(4) === a("4")) // true

Thanks,

Austin Cheney, CISSP

http://prettydiff.com/

Classification: UNCLASSIFIED - In these cases isn't it clearer ..

1. first if your input can be string or number, convert to a number (so ===

can be used etc)

2. check if the number isNaN

3. continue knowing your number variable really is number

Regards,

Luke

On 3 February 2011 17:16, Cheney, Edward A SSG RES USAR USARC <

austin.cheney@...> wrote:

>

[Non-text portions of this message have been removed]

>

> Classification: UNCLASSIFIED

>

> >

> > if (a !== a) {

> > }

> >

> > if (a === a) {

> > }

> >

>

> I use that logic to determine if a value, regardless of type, can become a

> number type.

>

> For instance:

>

> a = "4";

> if (Number(a) === Number(a)) // true

>

> b "4a";

> if (Number(b) === Number(b)) // false, because NaN does not equal NaN as

> they are type number, but are not a valid number.

>

> Further more you could have a comparison of functions where a number type

> is returned:

> a = function (x) {

> return (Number(x) + 3);

> }

> if (a(4) === a("4")) // true

>

> Thanks,

> Austin Cheney, CISSP

> http://prettydiff.com/

>

> Classification: UNCLASSIFIED

>

>

- Classification: UNCLASSIFIED

> 1. first if your input can be string or number, convert to a number (so ===

There is no reason to change a variable type to number if mathematical calculations are not being performed. More often than not merely testing for numbers is sufficient without conversion. Additionally, unnecessary type conversion is a security problem since math addition and string concatenation is identical and can result in undesirable consequences or unnecessary mitigating logic.

> can be used etc)

Austin Cheney, CISSP

http://prettydiff.com/

Classification: UNCLASSIFIED - This seems clearer:

a = "4";

if (isNaN(Number(a)) {

b = "4a";

if (isNaN(Number(b)) {

... but as soon as you call Number(..), you have already converted it to a

number. (see http://www.w3schools.com/jsref/jsref_Number.asp) Thus, in the

example ("if (Number(a) === Number(a)) {") you've actually converted it to a

number twice but still don't have a number var. If you are going to do math

with it, you'll need to convert it a third time.

I'd recommend something like this:

a = "4";

aN = Number(a);

if (isNaN(aN)) {

... which is basically what Luke said.

Rob

-----Original Message-----

From: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] On

Behalf Of Cheney, Edward A SSG RES USAR USARC

Sent: Thursday, February 03, 2011 10:16 AM

To: jslint_com@yahoogroups.com

Subject: Re: [jslint] Suggestion for error (UNCLASSIFIED)

Classification: UNCLASSIFIED

>

I use that logic to determine if a value, regardless of type, can become a

> if (a !== a) {

> }

>

> if (a === a) {

> }

>

number type.

For instance:

a = "4";

if (Number(a) === Number(a)) // true

b "4a";

if (Number(b) === Number(b)) // false, because NaN does not equal NaN as

they are type number, but are not a valid number.

Further more you could have a comparison of functions where a number type is

returned:

a = function (x) {

return (Number(x) + 3);

}

if (a(4) === a("4")) // true

Thanks,

Austin Cheney, CISSP

http://prettydiff.com/

Classification: UNCLASSIFIED - Classification: UNCLASSIFIED
> ... but as soon as you call Number(..), you have already converted it to a

That is only partially accurate. You do perform a conversion every time you use Number() or String(), but as long you do assign the responses of those function back onto the variable you are testing the conversion dies with the test. For instance:

a = "4";

if (Number(a) === a) // false, because variable a is still assigned a value of string 4 and has not been reassigned.

Fortunately, this matter of assignment versus type is simple with strings and numbers. Assignment is a bit more complicated when dealing with arrays and object literals. For instance:

a = ["a","b","c"];

b = a; // this does not do what you might expect, instead b is now a pointer to the contents of variable "a".

If you want to clone array "a" into array "b" you would have to do something like the following:

a = ["a", "b", "c"];

b = [].concat(a);

The moral of this story is that testing for conversion is not the same as an assignment and do not expect assignment to represent a uniquely assigned and wholly contained value.

Austin Cheney, CISSP

http://prettydiff.com/

Classification: UNCLASSIFIED