536
Surely "1337" is the same as 1337, right?
(sopuli.xyz)
Meme transcription:
Panel 1: Bilbo Baggins ponders, “After all… why should I care about the difference between int and String?
Panel 2: Bilbo Baggins is revealed to be an API developer. He continues, “JSON is always String, anyways…”
I’m not sure if you’re getting it, so I’ll explain just in case.
In computer science a few conventions have emerged on how numbers should be interpreted, depending on how they start:
0b, so0b10011100, so01160x, so0x8EIf your zip code starts with 9, it won’t be interpreted as octal. You’re fine.
Well, you're right. I wasn't getting it, but I've also never seen any piece of software that would treat a single leading zero as octal. That's just a recipe for disaster, and it should use
0o116to be unambiguous(I am a software engineer, but was assuming you meant it was hardcoded to parse as octal, not some weird auto-detect)
I thought JavaScript did that, but it turns out it doesn’t. I thought Java did that, but it turns out it doesn’t. Python did it until version 2.7: https://docs.python.org/2.7/library/functions.html#int. C still does it: https://en.cppreference.com/w/c/string/byte/strtol
Interesting that
strtolin C does that. I've always explicitly passed in base 10 or 16, but I didn't know it would auto-detect if you passed 0. TIL.It's been a long time, but I'm pretty sure C treats a leading zero as octal in source code. PHP and Node definitely do. Yes, it's a bad convention. It's much worse if that's being done by a runtime function that parses user input, though. I'm pretty sure I've seen that somewhere in the past, but no idea where. Doesn't seem likely to be common.
Node doesn’t.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/parseInt
You seem to have missed the important phrase "in source code", as well as the entire second part of my comment discussing that runtime functions that parse user input are different.