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

21–30 of 93 posts

Re: Writing C for Curl

#21

Post by voidUpdate »

Zambyte wrote: post #19
johnisgood wrote: post #2

> Code should be easy to read. It should be clear. No hiding code under clever constructs, fancy macros or overloading. I highly agree with this. I do not always want highly abstracted code, and some programming languages aiming to replace C are much more difficult to read, that said, Rust is supposed to replace C++, not C, right? Thank you for the article!

I have been playing around a lot with Zig lately, and though it's still in beta, it really feels like it has the best chance at being a true C successor. While Rust feels like they started with C++ and worked on making it harder to write incorrectly, Zig feels like they started with C and worked on making it easier to write correctly. They also have a few pillars that they call the "Zen" of Zig[0], of which three out…

I really want to start trying to learn zig, but right now I feel like it's not quite finished enough. When it hits 1.0, I'll probably give it a more serious look

Re: Writing C for Curl

#22

Post by uecker »

pornel wrote: post #18
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…

> Could such bugs be avoided in C using the right tools and strategies "right tools and strategies" is very open-ended, almost tautological — if you didn't catch the bug, then obviously you haven't used the right tools and the right strategies! In reality, the tools and strategies have flaws and limitations that turn such problem into "yes but actually no". Static analysis of C code has fundamental limits, so there a…

Static analysis of arbitrary legacy code is limited. But I do not find it difficult to structure my code in a way that I can reasonable exclude most errors. The discussion of false positives in C is interesting. In some sense, 99% of what the Rust compiler would complain about would be considered false positives in C. So if you want to have safety in C, you can not approach this from this angle. But this relates to my point. If it is acceptable to structure the code in specific ways to make the Rust compiler happy, but you do not accept that you may have to write code in specific ways to avoid false positives in C, then you are already not comparing apples to apples.

Re: Writing C for Curl

#23

Post by kpcyrd »

uecker wrote: post #13
kpcyrd wrote: post #10

> We count about 40% of our security vulnerabilities to date to have been the direct result of us using C instead of a memory-safe language alternative. This is however a much lower number than the 60-70% that are commonly repeated, originating from a few big companies and projects. There has been discussion in an Arch Linux internal channel about the accuracy of these classifications. We noticed many advisories cont…

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…

The blogpost claims they are already running "all the tools", can you please be more specific which one they are missing? Maybe the tool to avoid this kind of lifetime issue just happens to be rustc?

Re: Writing C for Curl

#24

Post by baumschubser »

MrMcCall wrote: post #3
johnisgood wrote: post #2

> Code should be easy to read. It should be clear. No hiding code under clever constructs, fancy macros or overloading. I highly agree with this. I do not always want highly abstracted code, and some programming languages aiming to replace C are much more difficult to read, that said, Rust is supposed to replace C++, not C, right? Thank you for the article!

The reality is that we spend FAR more time reading code than writing it. That is why readability is far more important than clever, line saving constructs. The key to further minimizing the mental load of reacquainting yourself with older existing code is to decide on a set of code patterns and then be fastidious in using them. And then, if you want to want to be able to easily write a parser for your own code (witho…

> The reality is that we spend FAR more time reading code than writing it. That is why readability is far more important than clever, line saving constructs.

In JS sometimes chain two or three inline-arrow-functions specifically for readability. When you read code, you often search for the needle of "the real thing" in a haystack of data formatting, API response prepping, localization, exception handling etc.

Sometimes those shorthand constructs help me to skip the not-so-relevant parts instead of mentally climbing down and up every sort and rename function.

That being said, I would not want this sentiment formalized in code guidelines :) And JS is not C except both have curly braces.

Re: Writing C for Curl

#25

Post by uecker »

kpcyrd wrote: post #23
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…

The blogpost claims they are already running "all the tools", can you please be more specific which one they are missing? Maybe the tool to avoid this kind of lifetime issue just happens to be rustc?

Rust is one tool which can be used to avoid life time issues. It is not the only tool. It also only works perfectly only when you exclusively limit yourself to using safe Rust and not use C libraries, unsafe Rust, or not directly use APIs that use integers (I assume in this example, Rust may have special safe wrappers, but in general the language also does not prevent this error). Resource management is something model checkers could verify in C. One could also design a safe API around it in C. Possibly GCC's analyzer could find such issues. In any case, the question is how much effort one wants to invest or not and what tradeoffs the solutions have. A small risk of missing such things may also be an entirely reasonable choice, even so Rust proponents irrationally claim otherwise. For example, curl uses C89 which is certainly not the best choice for safety. It is the best choice for portability to obscure platforms, but this requirement would also rule out Rust.

Re: Writing C for Curl

#26

Post by Almondsetat »

sebstefan wrote: post #14

The guidelines feel out of sync with the directions I've seen people push coding styles over the years "Identifiers should be short" when I've mostly seen people decry how annoying it is to find yourself in a codebase where everything is abbreviated C-style (htons, strstr, printf, wchar_t, _wfopen, fgetws, wcslen) There's a case for more verbosity and if you look at modern Curl code it reflects that as well, new iden…

There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors.

I don't thing good names will be solved soon

Re: Writing C for Curl

#27

Post by Galanwe »

kpcyrd wrote: post #10

> We count about 40% of our security vulnerabilities to date to have been the direct result of us using C instead of a memory-safe language alternative. This is however a much lower number than the 60-70% that are commonly repeated, originating from a few big companies and projects. There has been discussion in an Arch Linux internal channel about the accuracy of these classifications. We noticed many advisories cont…

> It was brought up because this disclaimer was also present in the CVE-2025-0665 advisory[0], which is essentially a double-free but on file descriptor level

I don't see how Rust would have prevented calling close() two times with the same eventfd.

Re: Writing C for Curl

#28

Post by masklinn »

johnisgood wrote: post #2

> Code should be easy to read. It should be clear. No hiding code under clever constructs, fancy macros or overloading. I highly agree with this. I do not always want highly abstracted code, and some programming languages aiming to replace C are much more difficult to read, that said, Rust is supposed to replace C++, not C, right? Thank you for the article!

> Rust is supposed to replace C++, not C, right?

Rust is intended as a systems langage. To the extent that it’s “supposed” to replace anything, it’s both.

Re: Writing C for Curl

#29

Post by Arch-TK »

veltas wrote: post #15

> So many people will now joke and say something about wide screens being available And this is a silly point because I want to be able to put 2-3 files side-by-side, on that big monitor. Who are all these people asking for long code that means I don't get more than one file on screen at a time?

It's not even just that. The reason newspapers have multiple columns rather than lengthy lines is because it's strictly easier to read shorter lines.

Re: Writing C for Curl

#30

Post by Munksgaard »

Galanwe wrote: post #27
kpcyrd wrote: post #10

> We count about 40% of our security vulnerabilities to date to have been the direct result of us using C instead of a memory-safe language alternative. This is however a much lower number than the 60-70% that are commonly repeated, originating from a few big companies and projects. There has been discussion in an Arch Linux internal channel about the accuracy of these classifications. We noticed many advisories cont…

> It was brought up because this disclaimer was also present in the CVE-2025-0665 advisory[0], which is essentially a double-free but on file descriptor level I don't see how Rust would have prevented calling close() two times with the same eventfd.

The same way Rust prevents calling close() two times on a file.
Post reply on HN