Morning, this question on secure memcpy for C over on security.stackexchange.com and originally on Stackoverflow has caused a bit of a religious war (which is why the stackoverflow one was pulled) but the original poster really wants to get a rational answer on safe and unsafe commands for non MS C.

So I thought I'd pop it up here as this is one of the few places I can think of that doesn't really do religious warring or irrational argument.

for those who don't use stackexchange, the original question is here:

I think the answer from ninefingers sums up my feelings on the issue. You can't ever make a really safe memcpy(), you just need to use it properly and test your code.

Using APIs like GLib and APR that do some memory management of data structures for you can be helpful, but ultimately, you're still free to memcpy() yourself into oblivion even when you use them exclusively, and the solution isn't to try to make memcpy safer, it's to use it properly, or not at all if you aren't disciplined enough for it (at which point, hopefully Clippy will pop up and recommend that you use Java or Ruby or something that keeps you from hanging yourself.)

There are "safe" variants of all these functions available on every platform.

That said, I was recently looking at a bunch of reported security vulnerabilities in common applications (student final projects in my security class), and a common feature was that several of these real-world apps were doing string handling by hand. Example: say you want to do an global substitution (s/something-long/short/g), I saw this hand-coded as a for-loop with two variables, writing the shortened string on top of the long string. There was a boundary condition they missed, and thus an exploitable vulnerability.

This boils down to this deep need among C hackers to micro-optimize absolutely everything and to handle strings directly rather than through libraries. Now, if somebody could tell me how to address these dual tendencies...

The funny thing is I bet if you compared some of this micro-optimized code to code that used conventional libraries the library code would be basically the same speed or close enough to not really be a factor. There is a lot of value in knowning when to start doing memcpy (or even inline assembler) to optimize something and when to leave well enough alone. It's not always obvious when to do this with today's very smart compilers, and libraries that have been highly optimized over the years.

I disagree. It's very obvious when to do this, and the answer is "after performance has been deemed unacceptable by the user, and profiling has demonstrated where the bottlenecks are."

This is what encapsulation is for; i.e. this is (part of) what C++ is for. When you've got C code which needs to be written in a certain stylised way -- disable_irq/enable_irq pairs, memory handling -- C++ often lets you design an API in which only safe programs can be expressed. (RAII and std::string respectively, for those two examples.)

This part of C++ (unlike some of the others e.g. exceptions, RTTI) requires no runtime support and is in theory no less efficient than the equivalent C would be if written-out.

So the "pure C, not C++" questioner has it backwards, i.e. has needlessly restricted the question to not permitting the actual answer. (Unless they're using such a restricted embedded system that C++ is way out -- perhaps on a DSP like those squalid Sigmatel things that Rio Chiba/Carbon/etc were made from.)

And yes, IMO Linus Torvalds is dead wrong on this. The kernel is chock-full of C++ -- all those fops and vops structures are in fact just vtables -- it's just that he quixotically prohibits all this C++ from being written in the normal idiom.

Peter

I think you need to add.. "and it can be proven that you could write something faster than the library". Unless your a wiz at counting clock cycles and understand modern assembler thoroughly (and how your compiler produces it) it really can be hard to beat a lot of library functions.

I thought that part was implicit in the profiling bit, i.e. if you haven't profiled your replacement to whatever the bottleneck is, then you have no idea if you've actually made an improvement.

Thanks for the comments there guys - like I said, I knew it would be a rational conversation here :-)

We missed our opportunity for irrational conversation when Pi day went past. Perhaps we can try again on Tau day.

The modern libata subsystem (SATA stuff) in Linux is an even better example of OOP: it uses object intheritence and the whole sheebang, elegantly done in C.

The choice of C for the kernel means it's easier to port to new platforms, requiring a less complex (aka. less buggy) compiler to get things up and running.

If one prefers to work with C++ in kernel space, then there are other kernels that do it that way.

Are you referring to the NT err I mean Windows kernel? It seems it's still mostly C for low-level stuff - with some C++ thrown in for higher level modules. At least that's what I remember reading. Of course MS gives developers a choice to use C or C++ for Kernel Mode Drivers with a nice long KB article about the Pros and Cons of each. Great light reading.