4 ms·

My bet is on url parser in unsafe language

by tester34 5y ago

junon 5y ago
You realize "safe" languages don't protect you from all bugs, right? So tired of this narrative on HN.
- tester34 5y ago
  From some bugs (or serious consequences in fact) they do, don't they?
  - junon 5y ago
    You can easily shoot yourself in the foot in any language.
    - tialaramex 5y ago
      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.
- erik_seaberg 5y ago
  Unsafe code can make even safe and correct code behave unpredictably, which is a lot more dangerous than merely crashing in an obvious way.
- chrismorgan 5y ago
  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.
  - tgv 5y ago
    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.
    - chrismorgan 5y ago
      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.
  - gpderetta 5y ago
    an uncaught exceptions or an abort can kill an application even on a safe language.
  - GuB-42 5y ago
    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.
DarkWiiPlayer 5y ago
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).
- hakre 5y ago
  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)

My bet is on url parser in unsafe language

junon 5y ago

You realize "safe" languages don't protect you from all bugs, right? So tired of this narrative on HN.

tester34 5y ago
From some bugs (or serious consequences in fact) they do, don't they?
- junon 5y ago
  You can easily shoot yourself in the foot in any language.
  - tialaramex 5y ago
    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.
erik_seaberg 5y ago
Unsafe code can make even safe and correct code behave unpredictably, which is a lot more dangerous than merely crashing in an obvious way.
chrismorgan 5y ago
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.
- tgv 5y ago
  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.
  - chrismorgan 5y ago
    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.
- gpderetta 5y ago
  an uncaught exceptions or an abort can kill an application even on a safe language.
- GuB-42 5y ago
  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.

DarkWiiPlayer 5y ago

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).

hakre 5y ago
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)