Comments on: The parseInt gotcha

By: peller

peller — Fri, 15 Feb 2008 17:15:14 +0000

@sphivo: wow, that article is a gem. How interesting that coercion takes hex strings but not octal. Plenty of gotchas with either method, I guess.

By: peller

peller — Fri, 15 Feb 2008 17:03:42 +0000

@MarkBirbeck: certainly no hatred intended on my part. I hope my comment wasn’t read as anything but constructive criticism. And yes, you give another very good reason why parseInt() is usually overkill and better replaced by coercion, IMO, unless you are doing it specifically because you want the behavior of parsing only the number portion.

By: p01

p01 — Wed, 13 Feb 2008 21:01:09 +0000

To ease the mood, here is another potential gotcha: per ECMAscript 262-3 specification, Array.prototype.sort( [compareFunction] ) is not necessary stable, and therefore should not be assumed to be stable.

By: p01

p01 — Wed, 13 Feb 2008 20:33:16 +0000

MarkBirbeck: Fair enough. If only the difference of time spent commenting on and stumbling on that parseInt() behavior and writting a blog post about it wasn't so big. FrankManno: I don't see hatred in the comments. Harshness yes but no hatred. Beside there are thousands of results when searching for parseInt 08 on the net.

By: FrankManno

FrankManno — Wed, 13 Feb 2008 15:33:59 +0000

I agree with MarkBirbeck on this one… Why the harshness? Since when are we all above “learning”?! This post may in fact help quite a few people who may be scratching their heads as to why parseInt doesn’t behave as expected.

Give the hating a break already!

By: MarkBirbeck

MarkBirbeck — Wed, 13 Feb 2008 11:52:38 +0000

Wow...give the guy a break! He didn't ask Ajaxian to make out this was some kind of major story. (Ajaxian has a habit of taking the most mundane stuff and giving it a high profile.) And also, some respondents might do well to follow their own advice and read the spec; on the one hand we're saying Guyon should read the spec, and in the same breath some people question why parseInt("08") returns 0 instead of NaN, proving that we can all overlook things, not just Guyon. The answer, for those who understandably don't want to wade through the specs (what are blogs for, after all), is that parseInt and related functions parse as much as they can from a string and then stop. So to illustrate, parseInt("23 days", 10) will return 23, and not Nan, because it will find as many base 10 numbers as it can before stopping. This means that the example of parseInt("08") might as well be parseInt("0banana") for all that it means in octal--the answer is correctly zero. Mark

By: kcisoul

kcisoul — Wed, 13 Feb 2008 01:43:23 +0000

I prefer this “String.prototype.parseInt=function(){return parseInt(this,10)}”

By: cdude

cdude — Tue, 12 Feb 2008 22:36:15 +0000

aww, if i had known ajaxian would accept any submission I would have submitted my discovery of mozilla’s setTimeout’s extra parameter (the lateness) long ago.

By: p01

p01 — Tue, 12 Feb 2008 21:05:12 +0000

Sorry Tim, I lost touch with reality when I saw someone actually blogging his revelation about parseInt(). Indeed parseInt( ’08′ ); should return NaN since 08 is not a valid octal number. :p

By: sphivo

sphivo — Tue, 12 Feb 2008 19:23:47 +0000

Just a FYI, the snippet I posted to the gumuz's blog using Prototype was just an example to show how the + operator responded to a list of date-like base-10 decimal strings. Obviously, there's nothing Prototype-specific about the + operator. You can read about it here: Javascript Type-Conversion. - Mike Owens

By: j4606

j4606 — Tue, 12 Feb 2008 18:36:22 +0000

But it worked yesterday? unfortunately the only thing that didn’t work was your ability to read the specs.

By: peller

peller — Tue, 12 Feb 2008 16:49:45 +0000

umm… Javascript is perfectly natural here, to the point where you typically shouldn’t resort to using parseInt! String->number coercion was the right solution all along, as the author discovered, and has exactly the behavior he was looking for — whether he used the plus trick or the explicit Number constructor or whatever. No need for fancy toolkits here until you need to iterate. He just shouldn’t have been using parseInt in the first place, which does very specific things which are also in line with the language, but obviously a bit more technical in nature (you might notice that number literals also respect the ohhh prefix!)

By: sebcreme

sebcreme — Tue, 12 Feb 2008 15:50:57 +0000

Considering javascript should be always as natural as possible to use why are we bother with plain old rules like “octal are starting with 0″ ? (which may be an old International Business Machine hack)
Should not be a real ohhh ?
like o12 or 12o

Everyone can live better with the ohhh !

By: jaredmellentine

jaredmellentine — Tue, 12 Feb 2008 15:25:11 +0000

Dion: You should probably run your code through JSLint (http://jslint.com/). It would have thrown an error about the radix missing.

By: jdalton

jdalton — Tue, 12 Feb 2008 14:43:42 +0000

His work around is pretty nice to, I have always used parseInt(foo, 10);

By: Diodeus

Diodeus — Tue, 12 Feb 2008 13:59:36 +0000

The reason it COULD return NAN is because 08 is the prefix indicating that the number *following* it is in octal. Since there is *nothing* following it NAN would make sense.

By: Joeri

Joeri — Tue, 12 Feb 2008 13:35:48 +0000

NaN is a well-defined concept from floating point arithmetic. Since parseInt is supposed to return an integer, it therefore shouldn’t return NaN.

By: Tim Cooijmans

Tim Cooijmans — Tue, 12 Feb 2008 13:08:45 +0000

Mathieu: I don’t see how NaN would be more ludicrous than 0 or 10. Other than that, yes, passing the radix argument is _the_ solution.

By: wortwart

wortwart — Tue, 12 Feb 2008 13:05:41 +0000

I know, cross-browser testing is out … I checked it on Firefox 2, IE7, Safari 3 Beta and Opera 9, all on Windows. They all returned 0, except Opera. Adding 10 as 2nd parameter to parseInt() returned the correct result in all 4 browsers.

By: ingdir

ingdir — Tue, 12 Feb 2008 12:15:11 +0000

Thank you. The simplest things are sometimes the most difficult ones to remember.