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

11–20 of 93 posts

Re: Writing C for Curl

#11

Post by dcminter »

> "Wider code is harder to read. Period. "

That's stated as if it were proven, and I can believe that it has enough basis in fact that one might choose to enforce it, but I don't believe it's universally true.

I do often see code subject to a line-length linting enforcement that I think would have been clearer not broken up across multiple lines.

Personally I prefer a linter with escape hatches so that you can declare "this line exempt from such and such a rule" if you have enough reason for it and are willing to take the fight to the pull request :D

Re: Writing C for Curl

#12

Post by kryptiskt »

MrMcCall wrote: post #5
johnisgood wrote: post #4

Earlier quoted context omitted.

> 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.

Abstraction is necessary to handle scale. If you have painstakingly arrived at a working solution for a complex problem like say locking, you want to be able to package it up and use it throughout your codebase. C lacks mechanisms to do this apart from using its incredibly brittle macro facility.

Re: Writing C for Curl

#13

Post by uecker »

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 and conclude this, one needs to compare apples to apples and then I find the reality looks differently, e.g. if a simple mitigation for the bug in C could not be used for some reason, but this reason would also prevent the use of another language in the first place, then using this as argument is misleading.

Re: Writing C for Curl

#14

Post by sebstefan »

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 identifiers aren't short

https://github.com/curl/curl/blob/master/lib/vquic/vquic.c

"Functions should be short" where I've mostly seen very negative feedback on codebases written following the trend of Uncle Bob's short functions. Complaints that hiding code in 10 levels of function calls isn't helpful, and that following rabbit holes is tedious even with modern editors

"Code should be narrow", "we enforce a strict 80 column maximum line length" I don't think I've seen that take lately. I remember seeing a few posts fly by about the number 80 specifically

You want to prevent dragging your eyes. For my IDE on default settings on a 1080p monitor, half of a 15" screen fits 100 characters

If you take away 20 columns to fit your text on less of the screen do you really get any benefits

What about the cascading effects on the code, like worse names, split lines, ...

In the end it's semi-interesting but we're all building sheds and these are mostly debates on what color the shed should be

Re: Writing C for Curl

#15

Post by veltas »

> 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?

Re: Writing C for Curl

#16

Post by tuetuopay »

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…

Everything is a balance. IMHO, the "identifiers should be short" "functions should be short" and such are knee-jerk reactions to overly long things that are common in some other languages (looking at you, Java). Like the practice of indicating the type, pointer, etc. Stuff ike `pWcharInputBuffer` and such.

There is a balance between `*p` and `inputPointerToMiddleOfBufferThatFrobnicates`.

Re: Writing C for Curl

#17

Post by johnisgood »

kryptiskt wrote: post #12
MrMcCall wrote: post #5

Earlier quoted context omitted.

Simplicity is essential to achieving managable complexity over time.

Abstraction is necessary to handle scale. If you have painstakingly arrived at a working solution for a complex problem like say locking, you want to be able to package it up and use it throughout your codebase. C lacks mechanisms to do this apart from using its incredibly brittle macro facility.

Ada has built-in constructs for concurrency, with contracts, and there is formal verification in a subset of Ada named SPARK, so Ada / SPARK is pretty good.

Re: Writing C for Curl

#18

Post by pornel »

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…

> 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 are bugs it can't find, and there are non-trivial bugs that it can't find without also finding false positives. False positives make developers needlessly tweak code that was correct, and leads to fatigue that makes them downplay and ignore the reports. The more reliable tools require catching problems at run-time, but problems like double-free often happen only in rare code paths that are hard to test for, and fuzzers can't reach all code either.

Re: Writing C for Curl

#19

Post by Zambyte »

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 of the first five are directly related to readability.

[0] https://ziglang.org/documentation/0.14.0/#Zen

Re: Writing C for Curl

#20

Post by MrMcCall »

kryptiskt wrote: post #12
MrMcCall wrote: post #5

Earlier quoted context omitted.

Simplicity is essential to achieving managable complexity over time.

Abstraction is necessary to handle scale. If you have painstakingly arrived at a working solution for a complex problem like say locking, you want to be able to package it up and use it throughout your codebase. C lacks mechanisms to do this apart from using its incredibly brittle macro facility.

> C lacks mechanisms to do this apart from using its incredibly brittle macro facility.

We programmers are the ultimate abstraction mechanism, and refining our techniques in pattern design and implementation in a codebase is our highest form of art. The list of patterns in the Gang-of-Four's "Design Patterns" are not as interesting as its first 50 pages, which are seminal.

From the organization of files in a project, to organization of projects, to class structure and use, to function design, to debug output, to variable naming as per scope, to commandline argument specification, to parsing, it's nothing but patterns upon patterns.

You're either doing patterns or you're doing one-offs, and one-offs are more brittle than C macros, are hard to comprehend later, and when you fix a bug in one, you've only fixed one bug, not an entire class of bugs.

Abstraction is the essense of programming, and abstraction is just pattern design and implementation in a codebase, the design of a functional block and how it's consumed over time.

The layering of abstractions is the most fundamental perspective on a codebase. They not only handle scale, they make or break correctness, ease of malleability, bug triage, performance, and comprehendability -- I'm sure I could find more.

The design of the layering of abstractions is the everything of a codebase.

The success of C's ability to let programmers create layers of abstractions is why C is the foundational language of the OS I'm using, as well as the browser I'm typing this message in. I'm guessing you are, too, and, while I could be wrong, it's not likely. And not a segfault in sight. The scale of Unix is unmatched.

Post reply on HN