Writing C for Curl
daniel.haxx.se
Writing C for Curl
1–10 of 93 posts
Re: Writing C for Curl
#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!
Re: Writing C for Curl
#3> 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 (without every detail in the spec), it's even more important.
And now that I have read TFA, I see he wrote:
> We have tooling that verify basic code style compliance.
His experience and dilligence has led him to the mountaintop, that being we must make ourselves mere cogs in a larger machine, self-limiting ourselves for the greater good of our future workload and production quality.
Re: Writing C for Curl
#4> 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…
> That is why readability is far more important than clever, line saving constructs.
Yes, I agree, that is why I am put off by some supposed C replacements that are trying to be clever with their abstractions or constructs.
Re: Writing C for Curl
#5Earlier quoted context omitted.
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…
> That is why readability is far more important than clever, line saving constructs. Yes, I agree, that is why I am put off by some supposed C replacements that are trying to be clever with their abstractions or constructs.
Simplicity is essential to achieving managable complexity over time.
Re: Writing C for Curl
#6Curl is one of the very few projects I managed to contribute to with a very simple PR.
At the time, I was a bit lost with their custom testing framework, but was very imprest by the ease of contributing to one of the most successful open-source project out there.
I now understand why. It is because of their rules around testing and readability (and the friendly attitude of Daniel Stenberg) that a novice like me managed to do it.
Re: Writing C for Curl
#7Earlier quoted context omitted.
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…
> That is why readability is far more important than clever, line saving constructs. Yes, I agree, that is why I am put off by some supposed C replacements that are trying to be clever with their abstractions or constructs.
Could you give an example of "clever" (bad) vs "simple" (good)?
In my experience C has a lot of simple grammar, a commonly-held simple (wrong) execution model, and a lot more complexity lurking underneath where it can't be so easily seen.
(One of my formative learning books was https://en.wikipedia.org/wiki/C_Traps_and_Pitfalls , valid in the 90s and mostly still valid today)
Re: Writing C for Curl
#8All his ideas are fantastic, and are obviously the result of long experience in a seasoned and highly successful project. He is sharing techniques that simply work for large, complex codebases. Ignore them at your peril!
Specifically, though, these sections are related, in my experience:
> Avoid "bad" functions
> Buffer functions
> Parsing functions
> Monitor memory function use
These related aspects are why I tend to wrap many library functions that I use (in any language environment) with my own wrapper function, even if it's to just localize their use into one single entry/use point. That allows me to have one way that I use the function, thereby giving my code a place to not only place all best practices for its use, but to allow me to update those best practices in one single place for the entire codebase. And it is especially helpful if I want to simply rewrite the code itself to, for example, never use scanf, which I determined was a necessary strategy many, many moons ago.
Now, when a single function needs to accomodate different use cases and doing such separate kinds of logic would incur too much logical or runtime cost, a separate wrapper can be added, but if the additional wrappers can utilize the cornerstone wrapper, that is the best, if feasible. Of course, all these wrappers should be located in the same chunk of code.
For C, especially, wrapper functions also allow me to have my own naming convention over top of the standard library's terse names (without using macros, because they're to be avoided). That makes it easier for me to remember its name, thereby further reducing cognitive load.
Re: Writing C for Curl
#9This is remarkably clear writing — you sense how it was formed by thousands upon thousands of hours spent communicating, really cool.
Re: Writing C for Curl
#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 contain a "This bug is not considered a C mistake. It is not likely to have been avoided had we not been using C."-disclaimer, but was unclear what the agenda was and how "C mistake" is defined.
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. The impact is extremely low (it's more "libcurl causing unsoundness in your process rather than can-be-exploited-into-RCE"), but it's a direct result of how C manages resources. This kind of bug can also occur in Python, but you're unlikely to find this kind of bug in Rust.
Could this bug have occurred with a programming language that isn't C? Yes. Could this bug have been avoided by using a programming language that isn't C? Also yes.