Local root vulnerability in snap-confine

Heh. The C string library functions routinely shows as "hot" when I benchmark certain programs because there's no way to use a view reliably (C++ helps out here, but if it were C…there wouldn't even be the ability to factor out that `strlen` from `if/else` trees at least using static strings). To use a substring, you have to allocate and copy it to new memory just to put a NUL at the end and that adds up over time. So I don't think performance is really the thing keeping C back from a new string library because it's frankly just not that great for string manipulation-heavy tasks to begin with IME.

As for convenience, sure it's handy to be able to pass a "string" around in a register because it's "just" the size of a pointer, but weighing that against the inconvenience of having to debug mishandling of these APIs, they are by *far* in the red in my book. I mean, we have how many flavors of "append a string"? `strcat`, `strncat`, and `strlcat`? Toss `snprintf` in there too if you want to be fancy. And there's not even *consensus* on this set. Reviewing code dense with use of the C string library requires notes because I need to track where lengths are coming from, are the right APIs being used, and "oh, that's just a poorly coded `strdup`" recognitions. I don't find it useful.

So given that it scores (IMO) a 2/5 on performance (sure, registers get you something I guess), 1/5 in (overall) convenience, and 0/5 on security because the APIs just don't help out half the time, why, specifically, would roc's "attitude" not be warranted?