Then, would risk cumulation be a better option ?
|
| Author | Content |
|---|---|
| nmset 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. |
| jdixon 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. |
| skelband 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. |
| jdixon 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. |
| penguinist 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. |
| mbaehrlxer Jul 08, 2019 2:34 AM EDT |
late to the party, but i'd like to add something to the initial question. in as much the code that makes up a language compiler or runtime is insecure, that potentially also makes the language it is running insecure. but, if you fix a problem in a language runtime, then that fix applies to all programs that are using that language runtime. that way, the effect of making code secure in a language runtime is multiplied. for example, in C you can create an array of a fixed size, and you can't easily extend it. you have to allocate new memory, and copy that array, you have to watch out that you only read as much data as the array size, etc. that's grossly simplified and probably only half accurate, but that's the point. it's not trivial. in python, creating an array is trivial, because the python developers already thought about how to make the array extensible. they did the hard work for us, so that the rest of us don't have to worry about the details. the downside sometimes is performance. if you need to send data at lightning speed, maybe a python array will not do. or maybe you want to do some uncommon operation on that array that python does not support. so it's simplifying the language, to make it easier to avoid mistakes. bufferoverflows are unheared of for example, because in python buffers can't overflow. they can in C, and if the python runtime has a bufferoverflow issue, it will affect you, until it is fixed, then you get the benefit without patching your own python code. (python is just an example here, replace any other language, ruby, php, javascript, pike, smalltalk, lisp, whatever) greetings, eMBee. |
| skelband Jul 09, 2019 12:20 PM EDT |
Was having an interesting discussion with one of my colleagues the other day about Rust. Rust is an interesting language to get into, and it has quite a steep learning curve. It does seem quite difficult to write code in Rust but it occurs to me that the reason for that is that it makes you consider object life cycle and ownership all of the time and like an annoying person continually points out your shortcomings in this regard. I kinda think that's the point. As a C and C++ programmer, you are only really on the ball regarding these important concepts part of the time and that's where the bugs creep in. Proper, secure and correct programming should be hard and Rust is difficult because it makes you do the donkey work. |
| nmset Jul 10, 2019 3:41 AM EDT |
There seems to be two reasonings in a choice of programing language that are more psycho-social than technical : 1. Do you agree to do the donkey work ? It yes, go C/C++. Your prize : more code control, less system resources used (no garbage collector). 2. Do you prefer to be cool ? If yes, the other languages. Your prize : more focus on application logic. There may be other non-technical considerations, like : is the programming toolkit under control of some company ? Look at the Java saga in court since Sun disappeared. But in the end, they will all do the job, and any job in any field is person-dependant. Thanks for your different views. |
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!