This isn't the first time a weird sequence of Unicode characters has caused the text renderer to crash and create problems for iOS users.
This is why we shouldn't be writing new code in C.
This is why we shouldn't be writing new code in C.
However the crash also occurs with a Bengali sequence, and ZWNJ does have an effect in Bengali, so that sequence is not "weird", if perhaps rare.
According to Wikipedia, the number of people speaking Telugu is 0.97% of the world. It's not even a statistical margin of error.
Still, how hard can it be to have a machine step through all of the possible combinations of every iOS-supported character set and jam them into iMessage to see if they're failsafe?
Depends on your priorities. I'd take occasional bugs over jitter, latency, CPU inefficiency, and excess memory usage. And all that in practical terms means C is very environmentally friendly.
>Mozilla made two previous attempts to parallelize its style system in C++, and both of them failed. But Rust’s fearless concurrency has made parallelism practical! https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-I...
Also, non-C languages frequently implement lots of library features on top of C because it would be a ton of work not to (and slower), which means any language could be at risk.
function ThisWillNeverCrash() {
console.log('hello');
stack.push('it');
setTimeout(ThisWillNeverCrash, 0);
setTimeout(ThisWillNeverCrash, 0);
// my point in posting this was to demonstrate a bug ... that array will eventually run out of memory and this loops infinitely but not using a standard language loop construct... but I see someone didn’t think that was relevant
Now, if they're talking about memory safety bugs...
[1] - https://github.com/kdeldycke/awesome-falsehood
[2] - https://www.joelonsoftware.com/2003/10/08/the-absolute-minim...
But largely the issue is, when an error occurs, can the state change to [undefined]. In some languages, like C/C++, it is possible through bugs to enter an undefined state. In many higher level languages, all states are defined even if not all states are actually handled by the developer's code.
If all states are defined you can use tooling to look for states which aren't handled by any execution path, and ideally handle them. If they remain unhandled there is a documented way to handle the unhandled known state (e.g. global exception handlers).
In a language with undefined states that isn't possible, all you can do is look for areas likely to result in an undefined state, but even that is easier said than done.
Higher level languages save you from a few classes of bugs, and make it easier to find bugs because things are more narrowly defined.
There is absolutely no such thing as "all states are defined". This has nothing to do with the language. There is nothing magical about a "higher level language" to safeguard from failures. At best you could be referring to managed languages, where memory access and exceptions are controlled and the extent of a aborted execution is predetermined - but still not immune to just closing a process when they misbehave. That is precisely what a process should do. Nonetheless, nothing in this bug report indicates that the system is acting in an undefined manner. The library that failed may have, by design, been programmed to close when font rendering reached these conditions. We don't know if this was a signal abort or an intentional if (bad_outcome) close()
Any level from the most managed sandboxed level to the most host level process may fail, regardless of the language used.