3 ms·
Safer languages cannot protect from bad design. Many libraries have implicit behaviour which is not always visible. It's a hard tradeoff to make. You want safet
by ludovicianul 4y ago
Safer languages cannot protect from bad design. Many libraries have implicit behaviour which is not always visible. It's a hard tradeoff to make. You want safety, but in the same time enough customisation and features. I worked recently with an http client library which was forbidding to send special characters in headers. I understand that this is a safety feature, but I really wanted to send weird characters (building a fuzzing tool).
- manbash 4y agoOK but we can mitigate these types of exploits (buffer overflow etc.) using memory-safe languages. Bad design is a universal orthogonal problem.
- ludovicianul 4y agoThat's true. It will definitely mitigate different category of exploits out of the box, but you still need people to acknowledge and be intentional about their decisions.
- Gigachad 4y agoSeatbelts can not save you from bad driving, but they certainly help mitigate the effects.
- lmm 4y agoSafer languages can protect from some kinds of bad design. Some kinds of incoherent design become simply impossible to express. (For example, using a structured language with function calls instead of goto means a function always returns to the same place where it was called from, so a whole class of possible designs - most of which were just mistakes, but a few of which were efficient implementations - becomes impossible)
- eru 4y agoOne job of language designers and compiler writers is to recover the efficient implementations without allowing the bad designs. See how eg optimized tail calls essentially give you back all the power of goto without the old downsides.