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

I've done this too. It's neat to watch a 'read-only' register on a PLC change because of a packet you sent it. Overflowing a buffer into an adjacent buffer remotely. It's an art that should have died long ago. PLCs need to be upgraded from C to C++ and devs should use standard C++ containers and remove all the fixed size C arrays.


> PLCs need to be upgraded from C to C++

You are implying that C++ code is generally safer than C code, even in the hands of developers who introduce buffer overruns in the first place.

This is so wrong I don't even know where to start. In C++, I doubt they will ever get it out of door. Which would solve the security problem, incidentally.


Modern C++ should be safer. If you keep dynamic memory allocation to a minimum, use the STL heavily and are OK with lots of copying then it's harder to screw up because there's not much manual freeing of stuff and buffer sizes are systematically checked.

Of course if you're going to leave C, why not use real time Java or some other safer language.... C++ doesn't seem like a very ambitious sort of upgrade.


software for setting parameters for hardware systems might not require complex logic. a language with formal verification would be a good idea in that case.


std::vector<whatever> in C++ is safe and is nothing at all like a fixed size array of whatever in C. People who don't understand this are ignorant of the facts. They are totally different languages. C++ is much safer than C. Go ahead and try to overflow std::vector<whatever>. You can't. It's not possible.

Also, it is relatively straight-forward to compile C code with a C++ compiler and adopt C++ constructs while throwing out all the old insecure C constructs. Doing this would vastly improve security and is achievable in a short period of time with little or no performance loss (it will probably run even faster).

Yet, all I read about on web forums such as HN are unattainable suggestions such as re-write X in the newest, non-standard, corporate backed/controlled language that isn't nearly as tested nor as performant as ISO Standard C++. Maybe it's just me, but I find these suggestions to be totally out of touch with reality and really uniformed about the vast differences between C and C++.


> std::vector<whatever> in C++ is safe

I may be remembering this incorrectly, but vec.at(x) is safe (i.e. does bounds checking), but vec[x] is not safe.

I'm going to try some test code here and check, but I'm pretty sure vec[x] will happily overflow.

Edit: https://gist.github.com/tonyarkles/e702e4d5b530a9b7cd3fc9837...

Definitely overflows and segfaults while unwinding the stack (presumably while deallocating the stack-allocated vector)


You can't overflow a vector. It's not a fixed size array. It grows automatically as needed.

What your example shows is an attempt to access a vector element that does not exist (std::out of range). And, that is undefined behavior and is documented.

Also, that code is 95% C (not C++). Even the includes and prints are C. Pure, idiomatic C++ would use iostream rather than stdio.h, and a vector iterator to access the elements rather than looping over the vector (in C like fashion) using an integer (which is unrelated to the vector) in an effort to access elements via index.


> You can't overflow a vector. It's not a fixed size array. It grows automatically as needed.

His example shows the precise opposite: the vector didn't grow automatically. Instead, memory outside the vector bounds was accessed, i.e., the vector overflowed.

Yes, idiomatic modern C++ makes that less likely, by reducing the use of explicit indexes. Even then, you still can overflow a vector with innocent-looking code.


> that is undefined behavior and is documented

In C, buffer overruns are undefined behavior and are documented. Back to square 1.


But can the compiler warn about such undefined behavior? Because if it can't, it's not much better than C.


I just tried:

    g++ -Wall -pedantic vec.cpp
And got no errors or warnings.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

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

Search: