3 ms·
>Picking any language that embraces bounds checking enabled by default, and proper string/arrays, is already a major improvement. Even bog standard C can be ma
by bigbizisverywyz 5y ago
>Picking any language that embraces bounds checking enabled by default, and proper string/arrays, is already a major improvement.
Even bog standard C can be made safe, and include bounds checking if you create and consistently use an API that supports that mindset - see for e.g. Microsoft's string safe lib (not that I'm saying that is the epitome of such a thing).
However the will and the effort has to be there, C is an incredibly flexible and capable language and can be as safe as you want it to be.
The last Random ascii article I read, he found an easily exploitable buffer overflow in iOS simply by checking the code to see where it used memmove and worked out the exploit from there, guessing correctly that there was no bounds checking. So it seems that the usual culprits are fairly easy to spot, but somebody needs to replace the worst APIs with something safer (memmove, memcpy, memset, malloc, a = b).
- pjmlp 5y agoAny "safe" string library for C that uses pointer and length as separate arguments is safe only in name. Microsoft does it, because it comes along with SAL[0], which is kind of Microsoft's own Frama-C. Also as long as WG14 doesn't care, everyone will keep passing char* around while hoping it is actually null terminated and points to the right place in memory. Technically, ISO C could get safer types, or have something like SAL/FORTIFY, but as you say, without will it will never happen. [0] - https://docs.microsoft.com/en-us/cpp/code-quality/using-sal-annotations-to-reduce-c-cpp-code-defects?view=msvc-170 https://docs.microsoft.com/en-us/cpp/code-quality/using-sal-...