

Another common bug in published code  - shawndumas
http://www.google.com/codesearch?hl=en&lr=&q=parseInt%5C%28*%5B%5E%2C%5D%5C%29&sbtn=Search

======
nbpoole
There's an important distinction between this code and the Math.random()
casting that you posted earlier (<http://news.ycombinator.com/item?id=2472223>
in case anyone missed it).

With parseInt, we're talking about best practices: if you fail to specify the
radix, your code may yield unexpected results (eg: parsing a number with a
leading 0 may cause parseInt to assume an octal base). On the other hand, your
code may still work fine if your inputs are properly formatted. In that case,
specifying the radix just enhances readability.

With casting Math.random(), what you saw was an actual bug: people were using
0's in their code when they thought they were getting random integers. Unless
the code was being written for an obfuscated Java contest, I'd wager it was
buggy.

~~~
tolmasky
Not sure why you don't think the missing radix is a "real" bug, there are
plenty of real use cases where a leading zero _is_ proper formatting, for
example, in spreadsheets that keep the same number of digits in each cell. Not
to mention that since this is all web code there is a good chance this is all
user input so anything goes.

~~~
nbpoole
My point is that specifying the radix is a best practice: there are still a
number of situations where it's unnecessary for properly functioning code (ie:
if you aren't using zero-padded numbers). Specifying the radix certainly helps
readability, but you can't just do a regex search and say that all the code it
finds is buggy.

On the other hand, casting Math.random() to an int is wrong unless you're
trying to express 0 in an obfuscated way.

~~~
podperson
Agreed. If you're calling parseInt on a variable it's simply not a bug.

parseInt(1) seems like a whole different class of bug to me :-)

------
shawndumas
If the input string begins with "0", radix is eight (octal). This feature is
non-standard, and some implementations deliberately do not support it (instead
using the radix 10). For this reason _always specify a radix_ when using
parseInt.

While the radix parameter is optional, _always specify it_ to eliminate reader
confusion and to guarantee predictable behavior. Different implementations
produce different results when a radix is not specified. [1]

\----

[1]:
[https://developer.mozilla.org/en/JavaScript/Reference/Global...](https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/parseInt#parameters)

~~~
cracki
that's not a bug, that's a feature.

a questionable feature, yes, but not a real bug.

~~~
InclinedPlane
It's a defect, it leads to inconsistent and unpredictable behavior. A better
default behavior would have been to use a default radix (base 10) and have an
option for auto-detected radix (e.g. strings that begin with 0x). Considering
how rare octal formatted integer strings are these days (essentially non-
existent) and how much more common 0 prefixed decimal formatted integer
strings are, this is definitely not a useful feature.

~~~
masklinn
> A better default behavior would have been to use a default radix (base 10)
> and have an option for auto-detected radix (e.g. strings that begin with
> 0x).

Note that the option exists (provide `0` as radix). It's just stupid that the
default radix is `0` (or `undefined`) and not `10`.

Not to mention, that would put parseInt in line with Number.toString(radix),
which (sensibly) defaults to base 10 (side note: I was surprised and impressed
to see that Number.toString can handle any base from 2 to 36 included)

------
jdp23
One of the lessons I took away from the static analysis tools I architected
(PREfix and PREfast) was just how many bugs you can find with simple pattern-
matching.

To make it work in practice, you need some UX support -- including
explanations (so in this case, making it clear that the results are undefined
if the integer starts with a 0) and recommended fixes (specify the radix).
Otherwise, people are likely to dismiss the messages as a false positive.

------
silvestrov
There's an uncommon bug in the regexp in the link: sequence count
metacharacters such as * are postfix, not prefix. (please ignore whitespace in
following regexps as the YA markup requires whitespace to avoid making text
italicized).

parseInt\\(* [^,]\\) means match "parseInt", then 0-or-more '(', then a
character that is not a comma, then ')'.

The regexp should be something like parseInt\\([^,()]* \\) which returns code
where the argument is more than a single character
[http://www.google.com/codesearch?hl=en&lr=&q=parseIn...](http://www.google.com/codesearch?hl=en&lr=&q=parseInt%5C%28%5B%5E%2C%28%29%5D*%5C%29)

~~~
paulbaumgart
FYI: <http://news.ycombinator.com/formatdoc>

------
Sephr
There is one exception where dropping the radix is the best option: when
you're parsing a format or programming language with hex, decimal, and octal
notations, such as Java in the case of processing.js.

------
estel
The headline figure of 22 million "bugs" can be reduced somewhat by
eliminating jQuery, which brings it down to 3% of this (600,000). Plus one.

~~~
ktsmith
Looks like a lot of these are in libraries. I see moo tools, tinymce and
others like that as well. There are possibly specific reasons why a library
author has chosen not to include the radix parameter, or they could just be
old versions as well.

