3 ms·

Are you seriously making the argument that a program reading untrusted data off a network should crash if it can’t parse the data? Programs should never, EVER

Are you seriously making the argument that a program reading untrusted data off a network should crash if it can’t parse the data? Programs should never, EVER crash. If you can’t decide/handle a Unicode codepoint, replace it with a question mark (or box etc) and carry on. And yes, a big-name program like iMessage absolutely should have unit tests for this. I can’t believe I’m having to explain this.

xenadu02 8y ago
I suggest you research font formats and the code required to render arbitrary unicode code points with case folding, reflow, ligatures, stacking, bidi, combining marks, etc. TrueType and OpenType are turing-complete all by themselves. There are nearly 140,000 Unicode code points; exhaustively testing the combinations is computationally infeasible. It is the definition of a decidedly non-trivial problem. Furthermore layout passes often involve hundreds or even many thousands of string measurements. Every platform has had numerous bugs, including exploitable ones, in font and string handling.
eridius 8y ago
The problem isn't with parsing the data. The problem is with triggering pathological cases in the complicated beast that is font rendering. And rendering text is something that's so extremely common in apps, and so crucial, that it needs to be done in-process in order to avoid unacceptable overhead.
zoul 8y ago
Programs should never, EVER crash. Oh yes they should. If, for example, the alternative is to continue in an undefined state, potentially corrupting user data. Not all error conditions are recoverable.
- feanaro 8y ago
  The right question to ask yourself is why this is the only alternative. It almost never is, if the program is properly designed, especially for a user-facing application.
  - zoul 8y ago
    As an example, the default reaction to accessing an invalid index in a Swift array is trapping. How would you solve this “properly”? Returning an optional (ie. Maybe) would be too cumbersome and wouldn’t lead to safer code in practice.

xenadu02 8y ago

I suggest you research font formats and the code required to render arbitrary unicode code points with case folding, reflow, ligatures, stacking, bidi, combining marks, etc. TrueType and OpenType are turing-complete all by themselves. There are nearly 140,000 Unicode code points; exhaustively testing the combinations is computationally infeasible. It is the definition of a decidedly non-trivial problem. Furthermore layout passes often involve hundreds or even many thousands of string measurements. Every platform has had numerous bugs, including exploitable ones, in font and string handling.

eridius 8y ago

The problem isn't with parsing the data. The problem is with triggering pathological cases in the complicated beast that is font rendering. And rendering text is something that's so extremely common in apps, and so crucial, that it needs to be done in-process in order to avoid unacceptable overhead.

zoul 8y ago

Programs should never, EVER crash. Oh yes they should. If, for example, the alternative is to continue in an undefined state, potentially corrupting user data. Not all error conditions are recoverable.

feanaro 8y ago
The right question to ask yourself is why this is the only alternative. It almost never is, if the program is properly designed, especially for a user-facing application.
- zoul 8y ago
  As an example, the default reaction to accessing an invalid index in a Swift array is trapping. How would you solve this “properly”? Returning an optional (ie. Maybe) would be too cumbersome and wouldn’t lead to safer code in practice.