3 ms·
>There are no safe array or safe string libraries, because they all fall appart under scrutiny, given C's approach to secure code. I do not understand, maybe g
by simion314 8y ago
>There are no safe array or safe string libraries, because they all fall appart under scrutiny, given C's approach to secure code.
I do not understand, maybe give an example.
About the history I am not sure that proves that UNIX and C advantage was only because of that, it could be a factor but there are merits to C and UNIX that if you want to disprove you can;t just do it by mentioning that history. I mean Windows API used C.
- pjmlp 8y ago> I do not understand, maybe give an example. Because since those libraries are not built-in types, you always need to convert back to a ptr and length values at some point when interoperating with other C code. And given the lack of bounds checking, you are back at square one. > I mean Windows API used C. Windows API used C, because by the time Windows came around UNIX was already well established in the enterprise. C spread outside UNIX, because many of us were using C dialects, e.g. Small-C, on personal computers when bringing work home from job/university.
- jstimpfle 8y ago> Because since those libraries are not built-in types, you always need to convert back to a ptr and length values at some point when interoperating with other C code. And that's exactly why C wins, in my opinion. Because that means interoperability. Storing a pointer + length pair in a fixed layout struct is bad from a normalization standpoint. They are independent data. If you don't separate them you will end up with data redundancies as soon as you have parallel arrays. If you use dynamic vectors and in C++ or similar languages and you ask yourself which is the object that you should call .size() on, that's when you notice that it's morally wrong to bundle pointer + length.
- pjmlp 8y agoThey are not independent, hence why 30 years since Morris worm, we keep increasing the amount of memory corruption exploits in C code. Or more precisely, 68% of Linux kernel exploits according to Google's talk at Linux Kernel Summit 2018.