Then, would risk cumulation be a better option ?

Story: These are the most insecure programming languagesTotal Replies: 4
Author Content

Mar 31, 2019
7:33 AM EDT
I may be wrong, but AFAIK, interpreted languages like Java, JavaScript, Python, Ruby, PHP... all sit on top of machine-code libraries (*.so) that have themselves been written in C/C++/assembly languages. In that case, the security holes of the interpreted languages would just add up with those of the machine languages. How would the CPU understand 'phpinfo()' literally ? Using plain C/C++ would then expose to less risk. I'm eager to read comments of knowledgeable readers.

Mar 31, 2019
9:19 AM EDT
OK, this is one person's perspective, and I don't even program for a living. But, as I understand things...

First, the headline is click bait and is a best a gross exaggeration. C isn't the most insecure language. If it was, the Linux kernel would be impossible to secure, and we know that's not the case.

C is the most popular language that it's possible to use in an insecure manner. C doesn't enforce security. If you tell it to do something that will produce an insecure program, it will do what you tell it. Other languages will yell and scream at you or even refuse to do so. C does what you tell it to do.

Claiming that language is insecure when it's actually the programmer that's at fault is disingenuous at best, IMO.


Apr 04, 2019
2:25 PM EDT
My take on this is that C allows you to do many low level things that are efficient but give you plenty of rope with which to hang yourself. I am a C programmer and I can tell you that there are a lot of things about C that I absolutely hate, one big one being the ambiguity of the sizes of integer types in the C standard.

One of the big problem with C is how flat it is. It doesn't provide any native mechanisms to abstract which is where C++ comes in, but I also consider C++ to be a complete hack.

I do have confidence in languages such as Rust where many well-solved problems like memory management, object life cycle, object ownership, simultaneous execution (i.e. threads) are encapsulated into the language in one way or another take away a lot of the boilerplate that bedevils other languages like C. C++ tries to do this, but it still has a lot of gotchas that stem from its C heritage and many fudges such as return value "optimization" which anybody but a crazy person would recognise for the kludges that they are.

Apr 05, 2019
6:43 AM EDT
> My take on this is that C allows you to do many low level things that are efficient but give you plenty of rope with which to hang yourself.

A fair assessment, from what I've read and the little time I've spent with C.

Apr 05, 2019
10:39 PM EDT
Is it my imagination or is it harder to make mistakes in c/c++ these days?

I remember when I first started with c it really was easy to hang yourself, but these days the compiler checking is really superb. Yes it is still possible to write buggy code, but now you just have to work harder at it.

@skelband: I agree with your comment about the ambiguity of integer type sizes. This is why I've adopted the practice of using the explicit types like uint32_t etc.

Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]

Becoming a member of LXer is easy and free. Join Us!