Hacker News Reader

Comment by hannob | Hacker News Reader

There's a lot right in this, but I feel he's chosen the wrong enemy by harshly criticizing Daniel Stenberg (the curl dev). He's not a C zealot, he's just accepting realities.

Curl should be replaced by something memory safe. But it cannot happen today, because the infrastructure isn't there. We don't have memory safe languages suitable for system programming that's widely available on all kinds of architectures. Rust may become that language, but today it is not. It's not as portable, not as easy to integrate etc. pp.

View on HN

I recommend looking at the top comment in https://news.ycombinator.com/item?id=13966241.

Stenberg said, and may believe, that C is not the source of most of curl's security problems. But examining counts of security vulnerabilities, it definitely is.

It's worth noting that those vulnerabilities appear to be from a security review; 10 of them were all posted on the same day (11/2/16). So the reality is that most of these didn't have practical impacts or attacks; they just needed to be fixed.

Putting that batch of 10 CVEs aside, the number of memory related bugs is quite small.

In the greater scope of things, ~60 CVEs over the course of 17 years is pretty small.

I don't understand your logic. The vulnerabilities were there. It doesn't matter who found them or when.

> It doesn't matter who found them or when.

It does matter. No vulnerability can be used without knowledge of that vulnerability, therefore it matters who found it (did they publish or abuse the vulnerability?) and when (was it published shortly after the first discovery?).

Some attacks don't get published, and the author specifically argues against comparing bug counts.

I disagree that you can infer anything about impact because they were found in an audit. That just means they weren't publicly known, it does not mean they weren't known to someone.

Not sure he's hitting on him but who knows :-) In any event, he is criticising Daniel Stenberg for downplaying the memory safety issues in curl. It looks like that criticism is justified to some degree.

Edited the post, thanks for the note :-)

My English is usually decent, but I still sometimes make stupid mistakes.

> We don't have memory safe languages suitable for system programming that's widely available on all kinds of architectures.

Yes, yes we do. Go is available on a ton of architectures; Lisp is available on a ton of architectures; ML is available on a ton of architectures.

Yes, C is available on more. Yes, for some architecture C is the only reasonable choice. But on x86 & ARM, there's no good reason to write new code in C.

What about kernel drivers?

Rust: https://github.com/tsgates/rust.ko

Haskell: https://wiki.haskell.org/Kernel_Modules

And you can find a few others.

I'm on Windows, though.

If you have experience and interest in windows kernel modules programming, tell me, what did you find in your research? Are the methods described in these posts portable to the win kernel? Are there some other barriers you know of?

As far as I know, the only languages supported for Windows kernel development are C and C++.

Rust can expose a C ABI, so that means you could write Rust ones too, same mechanism as the Linux ones.

The last time I looked, it seems there's a lot of platform work needed in Rust to support drivers in NT.

Same as Linux kernel. I asked because the links show it's possible with some effort and you seemed to dismiss it. If you know of some specific extra barriers in windows kernel, tell us. But if you just meant that it's not officially supported... yeah, that's not a big problem.

The Linux kernel does not allow for C++ code to be in-tree. There are folks who have managed to get some C++ code running in a kernel context, but I would consider it inadvisable.

> But on x86 & ARM, there's no good reason to write new code in C

Sorry, but this is pure ignorance. Please let me know when was the last time you've tried to implement a CFD or FEA code in Go or Lisp ?

http://www.sciencedirect.com/science/article/pii/08957177909... indicates that folks were writing computational fluid dynamics software in Lisp in 1989.

I think that http://www.femlisp.org/ is a finite element analysis for Common Lisp.

Folks were writing CFD codes in Matlab too, that does not mean that it was a good idea (except for 1D or small 2D problems or for prototyping). My point was that some languages are better suited for particular tasks. In CFD and FEM codes you want speed, if you need to wait a few days for a highly optimized C++ code to get some results (e.g. the flow around an entire airplane) imagine how long it will take to do the same in Go or Common Lisp ...

Case in point FEMLISP uses C or Fortran libraries (Triangle, Tetgen, OpenMP, various linear algebra libraries) under the hood for the actual computation :).

What about applications with soft or hard real time requirements? (So, for example, a video game or an audio player.) I am not aware of any GC language which is suitable for use in this space. Go certainly is not.

What about any application that cares in the slightest about performance? In this case, memory layout is incredibly important, and many (most?) of those higher level languages are immediately disqualified.

Correct me if I'm wrong as I'm not an expert in this field at all, but aren't hard real time systems written so that no memory allocation or release happens during normal operation?

I'm sure there are other reasons why Go would rarely be considered for a hard real time system, but purely from a memory management perspective you could simply disable the GC.

And then of course there is also Rust.

Rust was made specifically to fill this void. The only problem is that libraries you would want to use (ie for a video game or audio player) are written in C/C++, and therefore much easier to interface with using C/C++. Fortunately that is changing at a fairly good pace.

The most difficult thing about using Rust instead of C is that you must wrap your head around the borrow checker.

Reply on news.ycombinator.com