Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing C for Curl

daniel.haxx.se

Post reply on HN
Print view View original

81–90 of 93 posts

Re: Writing C for Curl

#81

Post by uecker »

pjmlp wrote: post #49
uecker wrote: post #13

Earlier quoted context omitted.

The question is: Could such bugs be avoided in C using the right tools and strategies. And the answer is also often: yes. This is why a large component of the argument for switching to other languages is usually that is impossible to avoid such bugs in C even for experts. But I think this argument, while having some small amount of truth to it, also is partially deceptive. One can not simply look at number of CVEs an…

It would help if since lint was created in 1979, the large majority of C developers actually used the right tools and strategies . In practice only when forced down MISRA like processes people seem to care, versus how relevant secure programming is seen in other programming language communities since 1960's. Secure programming was part of Burroughs and Multics design, so why is the answer from a systems language comm…

I think this is probably the reason why Rust is attractive to companies. They can say, "use Rust and never use unsafe without sign-off from some senior programmer" and then can be relatively sure there is no buffer overflow. In C you would say, you need to follow these guidelines with tools X, Y, Z and then you can be relatively sure there is no buffer overflow. The problem is that this is a striking argument only when the only thing you care about are memory safety issues. As soon as you care about other forms of security / correctness, you need "guidelines with tools X, Y, Z" anyway. And when you have mixed code base, you also need this anyway.

Re: Writing C for Curl

#82

Post by kobzol »

Great post!

I have some random guesses as to why the 40% vs 60-70% memory issues percentage:

- 180k is not that much code. The 60-70% number comes from Google and Microsoft, and they are dealing with way larger codebases. Of course, the size of the codebase in theory shouldn't affect the percentage, but I suspect in practice it does, as the larger the codebase is, the harder it is to enforce invariants and watch for all possible edge cases.

- A related aspect to that is that curl is primarily maintained by one person (you), or at most a handful of contributors. Of course many more people contribute to it, but there is a single maintainer who knows the whole codebase perfectly and can see behind all (or most) corners. For larger codebases with hundreds of people working on them, that is probably not the case.

- Curl is used by clients a lot (probably it's used more by clients than servers, for whatever definition of these words) over which you have no control and monitoring. That means that some UB or vulnerabilities that were triggered "in the wild", on the client side, might not ever be found. For Google/Microsoft, if we're talking about Chrome, Windows, web services etc., which are much more controled and monitored by their companies, I suspect that they are able to detect a larger fraction of vulnerabilities and issues than we are able to detect in curl.

- You write great code, love what you're doing and take pride in a job done well (again, if we scale this to a large codebase with hundreds of developers, it's quite hard to achieve the same level of quality and dedication there).

(sent this as a comment directly on the post, but it seems like it wasn't approved)

Re: Writing C for Curl

#83

Post by guappa »

bitwize wrote: post #50

> how do we write C in curl to make it safe and secure for billions of installations? "That's the neat thing -- you don't." Curl should do what fish did: bite the bullet and rewrite the damn thing in Rust.

That would mean no longer running on a lot of devices it currently runs on. Which would mean those devices would just use extremely out of date curl written in C.

Any other brilliant idea?

Re: Writing C for Curl

#84

Post by GTP »

uecker wrote: post #79
GTP wrote: post #35

Earlier quoted context omitted.

> If it is acceptable to structure the code in specific ways to make the Rust compiler happy I think this is a misleading way of presenting the issue. In Rust, there are class of bugs that no valid Rust code can have (unless maybe when using the "unsafe" keyword), while there is valid C code that has said bugs. And here's the difference: in Rust the compiler prevents some mistakes for you, while in C it is you that h…

The point was that you can not reject warnings as part of a solution for C because "it annoys programmers because it has false positives" while accepting Rust's borrow checker as a solution.

I think the general point of my comment still stands, as you and everyone else working on the project would need to be disciplined and only release binaries that were compiled with no warnings. And even using -Werror doesn't fully solve the problem in C, as not having warnings/errors is still not enough to get memory safety.

Re: Writing C for Curl

#85

Post by uecker »

GTP wrote: post #84
uecker wrote: post #79

Earlier quoted context omitted.

The point was that you can not reject warnings as part of a solution for C because "it annoys programmers because it has false positives" while accepting Rust's borrow checker as a solution.

I think the general point of my comment still stands, as you and everyone else working on the project would need to be disciplined and only release binaries that were compiled with no warnings. And even using -Werror doesn't fully solve the problem in C, as not having warnings/errors is still not enough to get memory safety.

I don't really disagree with you, but I was also making a slightly different point. If you need absolute memory safety, you can use Rust (without ever using unsafe)

But you get 99% this way with C, a bit of discipline, and tooling and this also means maintaining a super clean code base with many warnings activated even though they cause false positives. My point is that these false positives are not a valid argument why this strategy does not work or is inferior.

Your claim is that it is inferior because you only get 99% of safety and not 100%. But one can question whether you actually get 100% in Rust in practice in a project of relevant size and complexity, due to FFI and unsafe. One can also question whether 100% memory safety is all that important when there also many other issues to look out for, but this is a different argument.

Re: Writing C for Curl

#86

Post by pjmlp »

MrMcCall wrote: post #63
pjc50 wrote: post #61

Earlier quoted context omitted.

> The success of C's ability to let programmers create layers of abstractions You wrote several entirely valid paragraphs about how important abstractions are and then put this at the end, when C has been eclipsed by 40+ years of better abstractions.

Because programmers are creating the abstractions, not the programming language. And there is no OS I'm aware of that will threaten Unix's dominance any time soon. I'm not against it, but C's being so close to what microprocessors actually do seems to be story of of its success, now that I think about it. I personally haven't written in C for more than a half-decade, preferring Python, but everything I do in Python c…

> And there is no OS I'm aware of that will threaten Unix's dominance any time soon.

Depends on the point of view, and what computing models we are talking about.

While iDevices and Android have UNIX like bottom layer, the userspace has nothing to do with UNIX, developed in a mix of Objective-C, Swift, Java, Kotlin and C++.

There is no UNIX per se on game consoles, and even on Orbit OS, there is little of it left.

The famous Arduino sketches are written in C++ not C.

Windows, dominant in games industry to the point Valve failed to attract developers to write GNU/Linux games, and had to come up with Proton instead, it is not UNIX, the old style Win32 C code has been practically frozen since Windows XP, with very few additions, as since Windows Vista it became heavily based on C++ and .NET code.

macOS while being UNIX certified, the userspace that Apple cares about, or NeXT before the acquisition, has very little to do with UNIX and C, rather Objective-C, C++ and Swift.

On the cloud native space, with managed runtimes on application containers or serverless, the exact nature of the underlying kernel or type 1 hypervisor is mostly irrelevant for application developers.

Re: Writing C for Curl

#87

Post by Arch-TK »

Zambyte wrote: post #75
shepmaster wrote: post #52

Earlier quoted context omitted.

> [Rust and C++] encourages creating a library of types with inheritance You'll want to expand on and clarify your meaning here, as Rust does not have inheritance.

Traits encourage the same programming style, regardless of if it's technically inheritance or not.

I disagree completely.

It's not just a technicality, traits are not the same as multiple inheritance. They allow you to solve the same kinds of problems but traits don't introduce the mountain-loads of confusion, complexity and headache that multiple inheritance does.

Moreover, nothing forces you to use traits. You're just strictly better off using them in many cases. But you can always defer to writing overtly repetitive C style code if you want.

Re: Writing C for Curl

#88

Post by pjmlp »

Arch-TK wrote: post #87
Zambyte wrote: post #75

Earlier quoted context omitted.

Traits encourage the same programming style, regardless of if it's technically inheritance or not.

I disagree completely. It's not just a technicality, traits are not the same as multiple inheritance. They allow you to solve the same kinds of problems but traits don't introduce the mountain-loads of confusion, complexity and headache that multiple inheritance does. Moreover, nothing forces you to use traits. You're just strictly better off using them in many cases. But you can always defer to writing overtly repet…

Yet, I have zero issues mapping COM approach to OOP into Rust, because it turns out as per CS type systems theory, there are many ways to achieve the same goal.

Practical example, Raytracing in one weekend port from C++ to Rust, keeping the overall architecture.

Second example, Microsoft bindings to WinRT for Rust.

Re: Writing C for Curl

#89

Post by Zambyte »

Arch-TK wrote: post #87
Zambyte wrote: post #75

Earlier quoted context omitted.

Traits encourage the same programming style, regardless of if it's technically inheritance or not.

I disagree completely. It's not just a technicality, traits are not the same as multiple inheritance. They allow you to solve the same kinds of problems but traits don't introduce the mountain-loads of confusion, complexity and headache that multiple inheritance does. Moreover, nothing forces you to use traits. You're just strictly better off using them in many cases. But you can always defer to writing overtly repet…

I never said multiple inheritance.

Re: Writing C for Curl

#90

Post by Arch-TK »

Zambyte wrote: post #89
Arch-TK wrote: post #87

Earlier quoted context omitted.

I disagree completely. It's not just a technicality, traits are not the same as multiple inheritance. They allow you to solve the same kinds of problems but traits don't introduce the mountain-loads of confusion, complexity and headache that multiple inheritance does. Moreover, nothing forces you to use traits. You're just strictly better off using them in many cases. But you can always defer to writing overtly repet…

I never said multiple inheritance.

Multiple inheritance and SFINAE through templates are the only non-concept way of doing traits in C++

The way single inheritance is used in C++ is nothing like how traits are used in Rust.

Post reply on HN