I checked the character, it is anything but weird. It is a valid character in a language used by millions of people. For those curious: It is a Telugu character; Telugu is one of several widely spoken languages in India.

The ZWNJ is definitely weird -- ZWNJ on Telugu isn't really useful.

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.

I guess it depends on your definition of "widely spoken."

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?

[1]: https://en.wikipedia.org/wiki/Telugu_language

1%? Are you kidding? That's over 70 million. It's on the order of population of Germany, and 10 times more, than Swedes.

i think the metric isn't the right one. 1% is a small user base, but of that 1% how many of them have access to iphones?

>This is why we shouldn't be writing new code in C.

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.

Choose Rust. It has zero-overhead memory and data race safety.

I suppose so. As an embedded developer it appeals to me, but I haven't looked too much into it TBH. Do you know of any analysis done on the bugs in servo or any other large-ish project?

I haven't studied this extensively, but Mozilla made the following claim:

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

Right, I just wanted to examine it in the 'proof is in the pudding' sense where if Rust is as good as people claim, then certain types of bugs would be entirely eliminated. I'm usually weary of such claims :)

There are compartmentalization options, such as XPC Services on macOS (specialized sub-processes that can “crash” if something is risky).

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.

More like "this is why we should use LLVM's libFuzzer or similar". Apple is just not doing basic code hygiene stuff here.

Apple has been known to fuzz their code. Just because they didn't uncover this particular bug doesn't mean they didn't do any fuzzing, it just means the fuzzing didn't hit this case.

Fuzzing finds bugs, using a safe language precludes them.

No it doesn't. At best it precludes a certain class of bugs (which may be very significant, but it's not a silver bullet)

var stack = [];

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

What constitutes a safe language? Is Rust safe?

Not by the parent's definition, anyway. Rust code certainly has bugs; I know, I've written some!

Now, if they're talking about memory safety bugs...

We need a new "Falsehoods programmers believe about character encodings" article to be added to the falsehoods list [1]. Joel Spolsky wrote in 2003 about the dangers of the ignorance of character encodings [2].

[1] - https://github.com/kdeldycke/awesome-falsehood

[2] - https://www.joelonsoftware.com/2003/10/08/the-absolute-minim...

What causes this to be an issue in C but not in other languages?

It is in other languages just to be clear. C++ for one example could suffer from it.

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.

This is one of the most painfully ignorant things I have ever read.

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.