Hacker News Reader

Hacker News

Comment by tester34 | Hacker News Reader

Full thread

tester34

My bet is on url parser in unsafe language

View on HN

You realize "safe" languages don't protect you from all bugs, right?

So tired of this narrative on HN.

From some bugs (or serious consequences in fact) they do, don't they?

You can easily shoot yourself in the foot in any language.

For one thing that are plenty of toy languages where you'd be lucky to do anything in particular, including shoot yourself in the foot, "easily".

But also there are languages which have much higher bars for safety than you seem to have imagined. Notice how WUFFS doesn't have a "Hello, world." example program because printing out Hello, World is way too dangerous to be allowed in WUFFS even on purpose.

Unsafe code can make even safe and correct code behave unpredictably, which is a lot more dangerous than merely crashing in an obvious way.

But actual crashes are most likely due to memory unsafety; I’d be extremely surprised if the root cause was not found to be in a memory-unsafe language, though I doubt it’ll be in the URL parser.

That's a weak statement: isn't Chrome is almost entirely written in C++? I suppose you mean it's a memory overrun or use are free. You're probably right, then.

But in Rust, something like this could happen too, if someone added a panic!, e.g. on parsing a domain name with an empty component, or failure to put the domain name in a certain (external) structure. If the URL is parsed again on start-up, the application would be bricked. Granted, it's much easier to find and solve.

I would guess that various parts of Chrome for Android, especially its UI, might be in a memory-safe language. But yeah, in hindsight my word choice was poor; I should have said a root cause of memory unsafety.

As for Rust, if we’re talking about outright crashes (which on reflection I’m not sure if we actually are because of laxness in the definition of “crash”—I retract my proffered extreme surprise), panicking isn’t that (unless compiled with abort-on-panic or if a destructor panics while unwinding)—panicking is controlled and can (except for the cases already mentioned) be caught.

To be sure, you can still brick the app in the described way with persisted data triggering exceptions or panicking, but there at least can still be a difference.

an uncaught exceptions or an abort can kill an application even on a safe language.

Memory safe languages also have crashes, often uncaught exceptions, or explicit calls to abort() or similar functions (die, panic, etc...). Infinite recursion, and the resulting stack overflow is another common cause of crash that can happen in any language.

In fact, a crash (segmentation fault) is an exception. In theory, the program could catch it and try to recover from it, it is just that it is a terrible thing to do because you can't be sure of anything from now one.

In fact, letting the program crash is the basis of "offensive programming". This idea opposes the idea of defensive programming, where you try to be prepared for anything and try to do something sensible. In offensive programming, you crash when things are not as expected. For example, if you ask for the 5th element of a 4 element list, in the former, you return some kind of default value, in the latter, you crash with an "out of bounds" exception, or let a watchdog restart the system.

Both approaches have their pros and cons.

My bet is URL parser with insufficient tests.

It is well known that URLs are hard; nobody should ever trust their own implementation of a URL parser unless it is sufficiently tested (payload repositories exist for a reason).

And under circumstances testing the own url parser _alone_ is only half (?) of the story. The other URL parsers within the system or in the line need to be tested, too. Which mathematically might not be possible. So next to the URL parser it is likely practically to have an URL filter. And with it, a good test-suite, too.

(I don't do any bets thought, sorry)

Reply on news.ycombinator.com