PHP and Node definitely do.

Node doesn’t.

> parseInt('077')
77

1. If the input string, with leading whitespace and possible +/- signs removed, begins with 0x or 0X (a zero, followed by lowercase or uppercase X), radix is assumed to be 16 and the rest of the string is parsed as a hexadecimal number.
2. If the input string begins with any other value, the radix is 10 (decimal).

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/parseInt

I’ve also never seen any piece of software that would treat a single leading zero as octal

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

Only 3?

Darum geht’s nicht. Ich will Arbeits-Pizza.

JA ICH WEIẞ, DASS DAS DUMM IST.

ICH WILL PIZZA

Die Erklärung steht in der Pfosten-Beschreibung. Nach meinem initialen Schwall hat die Sache aber irgendwie ein Eigenleben entwickelt.

(Zangendeutsche jetzt wegsehen)

The explanation is in the post description. After my initial burst of memes, this topic seems to have taken on a life of its own…

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:

• decimal (the usual system with digits from 0 to 9): no prefix
• binary (digits 0 and 1): prefix 0b, so 0b1001110
• octal (digits 0 through 7): prefix 0, so 0116
• hexadecimal (digits 0 through 9 and then A through E): prefix 0x, so 0x8E

If your zip code starts with 9, it won’t be interpreted as octal. You’re fine.

It’s sad that (judging from this comment thread) people seem to agree that it’s ok to make unsubstantiated claims and get pissy when you challenge them. Oh jeez I wonder why a US president can get away with spouting nonsense all the time.

Frankly that there isn’t a specific field signalling authorized/not-authorized

The instance I was bitching about was this: There’s a lot of region-specific data coming from the backend. But the user is only authorized for certain regions. So for instance the North-American guy gets this object: { "CA": [/* list of stuff */], "US": [/* list of stuff */], "MX": [ /* list of stuff */ ]}, while the US-only guy only gets {"US": [ /* list of stuff */] }. Are you suggesting that the response should also include flags isCaPresent, isUsPresent, isMxPresent for every country?

The issue with null vs not present surfaced because I, the frontend, checked if the returned object contained the key "CA" and then tried to iterate over the list of stuff, which happened to be null, which is hard to iterate over. I agree that I could’ve checked if the key was present and not null.

The meme, however, was lamenting that the backend developer, refuses to acknowledge that these two JSONs are different,since they only see their POJOs, where both map to CA: null, US: [], MX: null.

they also pay 3000$/mo for a moldy apartment

the rule is flagging a false negative

false positive?

Yes, I know the field isn’t nullable in the database. I’m asking you what you are sending me, jack——

(Directed at a colleague)

try to stick with integers in a currency’s smallest unit of division

And then the marketing department comes up with products that cost 1.5ct apiece.

Hell, no. If I wanted to save bytes, I’d use a binary format, or just fucking zip the JSON. Looking at a request-response pair and quickly understanding the transferred data is invaluable.

I’m sad that there are people who call themselves developers who need to be told this.

Both instances are legal serialized JSON. What makes you think otherwise?

So it sounds like an issue with […] handling per-spec the presence of data which you don’t use.

The trouble is, in this specific use case, the data may either be there or it may not be, depending on authorization. I’m checking specifically if the key is present to determine whether the user has access to that data (and display a toggle for that data), or if the user mustn’t see it and thus doesn’t need the toggle.

The wrong assumption was that if the key is there, then the value is not null. That assumption was invalidated by an update on the server side. Of course I could’ve checked if the value of the key is nullish. But it’s still annoying to have a breaking frontend because the backend changed how it serves its data.

Und er hat Corona nicht direkt in der Küche eingespannt? Nett von ihm.

I refuse to validate data that comes from the backend I specifically develop against.

Probably so ships don’t bump into it?

Or even funnier: It gets parsed in octal, which does yield a valid zip code. Good luck finding that.