4 ms·
They're at least spatially memory safe (bounds checks), which already helps a lot since buffer overflows account for more than 20000 vulnerabilities over the ye
by sirwhinesalot 3y ago
They're at least spatially memory safe (bounds checks), which already helps a lot since buffer overflows account for more than 20000 vulnerabilities over the years.
C is allergic to fat pointers for reasons I don't understand and the bounds safe .at() method of std::span in C++ is only coming in C++26.
These two languages have a serious attitude problem towards security.
Also Delphi uses automated reference counting, bringing it more inline with Swift rather than your typical C++ codebase. (though sadly the implementation is a bit error prone due to the object/interface reference distinction)
- crq-yml 3y agoAgreed, there's profound difference between "default runtime checks for common issues, can inline a toggle to disable" (which describes both Delphi and Ada) and the C "do it yourself kid" or C++ "we have a template for that" approach.
- eqvinox 3y ago> C is allergic to fat pointers for reasons I don't understand I do understand not making "some_type *" a fat pointer, since that makes it difficult to interface with another language's fat pointers. On a library/API level lots of libraries use fat pointers of various incompatible kinds. The best thing C could IMHO do is add a fat pointer variant to the ISO C standard library functions, plus syntactic sugar. Unfortunately this chafes against "conservative" inertia :(
- sirwhinesalot 3y agoNobody wanted to make "some_type *" a fat pointer, everyone wanted a new syntax. Maybe it was an issue of constant bikeshedding on what exactly that syntax should have been? I like Walter Bright's proposal of "some_type[..]".