Das Verhalten zeigen nicht alle Browser (Chrome ist Gegenbeispiel) und „kurz“ ist ein relativer Begriff. Ich meine ja auch nur, dass es angenehm ist, dass der Standard das Problem nun doch recht eindeutig klärt.

Mit IE meine ich den Internet Explorer. Und der IE 3 war irgend ein beliebiges Beispiel für einen sehr alten Browser.

Das mit dem Nischenbrowser war Ironie.

Aber darum geht es ja: Man müsste eben nicht den zweiten Parameter verwenden, da der Standard vorsieht, dass auch parseInt(„08“) === 8 ist. Der zweite Parameter wäre demnach nur notwendig wenn man eine andere Basis als 10 verwenden möchte (was selten genug der Fall ist).

Leider halten sich einige Browser (wie offensichtlich der Firefox) nicht an den Standard; sie verhalten sich diesbezüglich falsch und interpretieren diese Zahlen als Oktalzahlen.

Das ist ECMA 5, wo das nicht mehr der Fall ist. Das ist ganz aktuell und noch nicht alles wird von allen Browsern umgesetzt. ECMA 3 hat nichts mit IE 3 zu tun, falls ich deine Bemerkung oben richtig verstanden habe.

alert(parseInt('0x15'));

Deshlab bei parseInt() immer den zweiten Parameter benutzen.

Sag ich ja, solche Fehler treten nur in Nischenbrowsern auf. Wer nimmt denn schon noch Rücksicht auf den Firefox 😉

Wie schlecht, vor allem da Mozilla selbst noch darauf hinweist, dass dieses Verhalten falsch ist.

Heißt das, dass du schon mal den konkreten Fall hattest, in dem der Browser wegen ner 0 davor in den Oktalmodus geschaltet hat?