On 02/18/2016 12:35 PM, Moby wrote:
The key is programming habits. Most low level code (kernel, system libs etc) are done in C/C++, hence most juicy buffer overflow targets rely on mistakes in C/C++ code. Write the low level code in another language, and you will be bad mouthing it just as much. Key is bad programming habits, not the language.
No, its not that simple. First, we are talking the kernel here. Bugs are more critical than elsewhere. Secondly, there are many other situations where "performance" is in demand but issues like production, maintainability and more are of greater importance. You might note that, for example, web sites tend to be written in the kind of languages, Perl, Python, Ruby, that have string handling that voids input buffer overflow such as we have been discussing. Yes there are other classes of errors, especially when the coders are let loose on the raw interface rather than using a CMS package that avoids many egregious mistakes. Again, its a issue of leverage. Productivity matter more, and productivity includes maintainability. C and especially C++ are not the most maintainable of languages, which is, in turn, part of the problem. Nothing new here. Assembler was worse as far as intelligibility goes. Its why HLLs came along. More expressive detail, hide code optimization, error handling and more in the complier and run-time packages, libraries. Compilers are really "expert systems" in code generation, embodying the skills and knowledge of many experts. and able to produce optimized code day-in, day-out, which is more than can be said for assembly code programmers. They are productivity amplifiers. The higher the HLL the greater the amplification, as packages such a RubyOnRails and its Perl and Python counterparts are showing. The thing is to differentiate between true compilers and interpreters, even bytecode interpreters. Are these HLLs impervious to errors? of course not, but they do avoid so many of the errors of C-as-structured-assembler. Even so, its not simply an issue of productivity. These HLLs are also more resilient because they are focusing on expressive power rather than the fiddly bits of implementation. Could large swaths of the kernel be implemented in a HLL? Yes. Even back in the 1980s Bill Joy of BSD fame was showing Dave Cutler[1] of VAX/VMS that a "HLL" (it *was* C) was more productive, more responsive in making changes, than assembler. Back then we didn't have the powerful compilers and code generation expertise we have now, so a LLL was needed. But it made the point: you don't need assembler to code the OS and device drivers. Taking a walk through the literature from the days before Linux became dominant you will find many vendors made use of HLLs for OS design and implementation. All Brinch Hansen's work on concurrent programming and kernel support for the same was done with Pascal. His classic work on operating system principles starts with the assertion that the needs of a OS are not radically different from other programs that require efficient and reliable design and operation. Similarly Wirth's "Algorithms + data structures = programs" from the same era made the point that reinforced his papers on multiprogramming that so much begins with good design. When you speak of bad habits, the worst is "coding first" which stems from the attitude that programming schools & courses have that teach coding, syntax and grammar, and not design. [1] https://en.wikipedia.org/wiki/Dave_Cutler#Attitude_towards_Unix -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org