Mailinglist Archive: opensuse (1470 mails)

< Previous Next >
Re: [opensuse] Now what? Glibc bug, vulnerability
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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >