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

61–70 of 93 posts

Re: Writing C for Curl

#61

Post by pjc50 »

MrMcCall wrote: post #20
kryptiskt wrote: post #12

Earlier quoted context omitted.

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,…

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

Re: Writing C for Curl

#63

Post by MrMcCall »

pjc50 wrote: post #61
MrMcCall wrote: post #20

Earlier quoted context omitted.

> 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,…

> 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 could be done in C, with enough scaffolding. In fact, Python is written in C, which makes sense because C++ would introduce too many byproducts to the tightness required of it.

I was programming C using my own object structuring abstractions as C++ was being developed and released. It can be done, and done well (as evidenced by curl), but it just requires more care, which comes down to the abstractions we choose.

So, I would say "eclipsed" is a bit strong a sentiment, especially given our newly favorite programming langauges are running on OSes written in C.

If I had my druthers, I'd like everything to be F# with native compilation (i.e. not running using the .NET JIT), or OCaml with a more C-ish style of variable instantiation and no GC. But the impedance mismatch likely makes F# a poor choice for producing the kinds of precise abstractions needed for an OS, but that's just my opinion. Regardless, the code that runs runs via the microprocessor so the question really is, "What kinds of programming abstractions produce code that runs well on a microprocessor."

I've never thought of this before, thanks for the great question.

Re: Writing C for Curl

#64

Post by stzsch »

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…

Seems similar to the linux kernel coding style: https://www.kernel.org/doc/html/latest/process/coding-style....

Re: Writing C for Curl

#65

Post by MrMcCall »

kllrnohj wrote: post #51
MrMcCall wrote: post #20

Earlier quoted context omitted.

> 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,…

> 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. What browser are you using that has any appreciable amount of C in it? They all went C++ ages ago because it has much better abstraction and organization capabilities.

That's a fair point that I hadn't considered. I was developing C+objects as C++ was first being released in the mid-90s, and then using Borland's C++ compiler in the early 2000s, but never really thought about it as anything more than what its name implies: "C with some more abstractions on top of it".

Thank you for the correction, but I consider C++ to be just a set of abstractions built upon C, and, if you think about it, and none of those structures are separate from C, but merely overlaid upon it. I mean it is still just ints, floats, and pointers grouped using fancier abstractions. Yes, they're often nicer and much easier to use than what I had to do to write a GUI on top of extended DOS, but it's all just wrappers around C, IMO.

Re: Writing C for Curl

#66

Post by Arch-TK »

timhh wrote: post #42
Arch-TK wrote: post #29

Earlier quoted context omitted.

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.

I don't think anyone disagrees with that, but 80 characters is clearly waaay too restrictive. I think 120 is much more reasonable.

Clearly to whom? I think it works fine in C with 8 spaces per indent level. It works fine in python and rust with 4 spaces per indent level. For some languages I think it's worth going down to 3 spaces per indent level. But I've not hit that many languages where it's worth going much past 80 characters.

Re: Writing C for Curl

#67

Post by pjc50 »

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…

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

True, but irrelevant?

> What kinds of programming abstractions produce code that runs well on a microprocessor

.. securely. Yes, this can be done in C-with-proofs (sel4), but the cost is rather high.

To a certain extent microprocessors have co-evolved with C because of the need to run the same code that already exists. And existing systems force new work to be done with C linkage. But the ongoing CVE pressure is never going to go away.

Re: Writing C for Curl

#68

Post by johnisgood »

voidUpdate wrote: post #58
woodrowbarlow wrote: post #56

Earlier quoted context omitted.

Zig is friendly for soft-transitions because the compiler can compile C code. you can use Zig tooling for a C codebase, and then slowly add Zig code where it makes the most sense.

Well I was debating learning C this year, but Zig seems like the more attractive option. I'd be starting new projects from scratch

I think it is still useful to learn C, however. For personal projects you could use Zig, but it is still good to know C. C is like the lingua franca of programming languages, and some assembly (if you care about optimization, for example).

Re: Writing C for Curl

#69

Post by woodrowbarlow »

voidUpdate wrote: post #58
woodrowbarlow wrote: post #56

Earlier quoted context omitted.

Zig is friendly for soft-transitions because the compiler can compile C code. you can use Zig tooling for a C codebase, and then slowly add Zig code where it makes the most sense.

Well I was debating learning C this year, but Zig seems like the more attractive option. I'd be starting new projects from scratch

ahh, ideally i'd say learning them in any order is fine but unfortunately since the zig ecosystem is not mature yet that means you'll find yourself using C libraries from zig fairly often.

so, yes, i agree learning zig is a great idea for new independent projects but (at the current stage) be prepared to also learn at least enough about C to use C libraries (return type conventions, raw enums, c-style strings, inflexible allocators).

Re: Writing C for Curl

#70

Post by aaronmdjones »

zxilly wrote: post #45
coliveira wrote: post #34

Earlier quoted context omitted.

The problem is not as much C, but coding practices that make it seem like we're still in the 1970s. Codebases like curl use C at a very low level. But C has functions, has structures, has a lot of functionality to allow you to write at a higher level, instead of chasing pointers at each while statement. Code that handles pointers could be abstracted in the same way people will have to do in other languages.

What about performance overheads? I think the reason a lot of people write C is that they have direct control over the generated assembly to maximise performance.

Even direct control over the generated assembly (C does not provide this; only writing assembler does, and only if you don't do things like LTO) is not sufficient.

Modern CPUs do all sorts of weird things. Assembly instructions can be executed out of order. Your conditional jump instruction can be speculatively executed before the condition's truth is known. Fetches from main memory can be reordered.

Even more wildly, copying the contents of one register to another is often a no-op. Yes, that's right; the following code:

    mov edx, eax
... does next to nothing on some modern CPUs. All it does sometimes is set an internal note to the effect of "later references to edx should read/write eax instead", until that note is cleared by some other operation.

You can write your assembler with the best of intentions as to how it should behave, only to discover that the CPU does things entirely differently. You still end up getting the same observable result out of it, but any timing and order of operation guarantees went out the window decades ago.

Post reply on HN