- implicit conversions
- decays from enums to integers
- implicit conversiosn from integers to unexisting enums
- no bounds checking
- implicit conversions between pointers and arrays
- no proper way to ensure a given array length is valid as part of a function parameter
- null terminated strings, that occasionally aren't terminated
- abusing null terminated strings with clever algorithms, e.g. strtok()
- the preprocessor
- const that isn't really const
- variable arguments that require getting the macro type arguments
- UB explored to the last possibility of code optimization
- no safe way to deal with output parameters
- typedef don't introduce strong typing
All of that came from C, not C++.
Manageable in C. Integer conversions are only a tiny fraction of all the other implicitness in C++.
> decays from enums to integers
Compiler warns. Recent real compilers like gcc even have exhaustiveness checks like OCaml.
> implicit conversions from integers to unexisting enums.
Compiler warns.
- no bounds checking
Reason about that and implement your own scheme. Or prove.
> implicit conversions between pointers and arrays
Have not seen a single bug due to that in more than 1000000 lines of C.
> null terminated strings, that occasionally aren't terminated
Have not seen a bug due to that, this is the canonical example of an overblown hypothetical threat.
> abusing null terminated strings with clever algorithms, e.g. strtok()
Prove the algorithm or don't use it. Hint: As far as proofs are concerned, NUL terminated strings are like Lisp lists terminated with NIL, hence a well-founded data structure that is easily amenable to proofs (unlike C++ constructs).
- the preprocessor
Rarely introduces anything and is still required for C++, especially in sane test suites.
I don't think all that came from C, things like typedef being an alias rather than a separate type seem much older.
You are again just throwing dirt at C, mocking all people who write actually robust buzzword free software.
You are ignoring that C code is much easier for formal proofs that C++ code (the kind that you advocate).
Which happen to be written in C with several layers of code review and static analysis.
So by your reasoning those 32 years have not happened, in spite of being so easy to prevent exploits in C code.
Yeah, right.
All while their own industrial strength C++-OS (according to you) never has any exploits.
The fact that you are singling out Linux shows that you are only interested in throwing dirt.
I wonder why.
Here is a little tip for you, Microsoft has been acknowledging security issues with C and C++ since the XP SP2 days.
Which is why Windows happens to have plenty of mitigations that only recently FOSS UNIX clones are catching up to.
Yet they have come public that hasn't been enough, hence the migration effort away from C, enforcing programming guidelines with C++ and coming up with plans to migrate to safer systems programming languages.
Guess which OS vendor is now having first party support for writing GUIs in Rust?
But I can also rephrase what Oracle, Apple and Google have stated in the same vein regarding OS security.
Or maybe you prefer the statements of an UNIX hero instead?
https://news.ycombinator.com/item?id=23290030
I would argue that the closer you stay to C while using the good features of C++, the safer the code is.
And obviously well written and debugged C code is nearly always more robust than C++ code. But for ideological reasons most people here are unable to acknowledge that, perhaps because they cannot do it.