Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It has nothing to do with C style coding. The worst offenders are the latest and greatest features, as described brilliantly in this very thread:

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.



Quite on the contrary, the worst offenders are:

- 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++.


> implicit conversions

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).


You are ignoring 32 years of proven C exploits since Morris worm introduced in 1988, UNIX kernel exploits, including those that Linux collects every year, which lead to Microsoft (Azure Sphere), Google (Android 11), Apple (iPhone X) and Oracle (Solaris SPARC) enforcing hardware memory tagging.

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.


Oh, poor Microsoft is forced to use bad bad C-Linux on their Interweb service!

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.


Are you joking? Both C and C++ are equally littered with unsafe "features".


I can give you as many UNIX security exploit examples as you feel like having, no need to single out Linux.


It is not about UNIX vs. Linux, it is about the fact that you are always protecting Microsoft, like just now.

I wonder why.


Someone woke up in the 90's it seems.

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?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: