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

51–60 of 93 posts

Re: Writing C for Curl

#51

Post by kllrnohj »

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

Re: Writing C for Curl

#52

Post by shepmaster »

Zambyte wrote: post #39
Arch-TK wrote: post #32

Earlier quoted context omitted.

I used to think rust was like C++ but harder to write badly but I don't think it's anything like C++ now that I've spent a couple of years writing it. Rust is its own thing, it has none of the extensive baggage of C++, and doesn't appear to be set to reach that level of baggage at any point in time soon if ever. It's a much cleaner, clearer, and easier to reason about programming language.

The lack of baggage is definitely a huge improvement, but I believe Zig also has this advantage over C. Rust and C++ also seem to encourage a similar style of programming (particularly newer C++), and so do Zig and C. The former encourages creating a library of types with inheritance, using syntactic sugar where applicable (ie operator overloading), and a functional style, whereas the latter limits the programmer to…

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

Re: Writing C for Curl

#53

Post by pjmlp »

coliveira wrote: post #34
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 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.

Bell Labs 1970s, I advise learning about what already existed elsewhere in systems programming languages.

Re: Writing C for Curl

#54

Post by kpcyrd »

uecker wrote: post #25
kpcyrd wrote: post #23

Earlier quoted context omitted.

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

> It is not the only tool

The burden of proof is on you. I asked which tool specifically would have detected CVE-2025-0665 and I don't mean to be mean, but your reply is essentially a very confident "I don't know but I'm sure somebody could build one", while also handwaving the security benefits of programming in Rust.

When building a http client library, unsafe Rust and C FFI are not really a problem I'm having.

Re: Writing C for Curl

#55

Post by pjmlp »

im3w1l wrote: post #43
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…

For all it's many faults, even C++ fstreams is not vulnerable to double freeing (and as a partial reply to @Galanwe, they way they avoid issues is runtime checking).

Already in early 1990s, with C++ARM as the first standard, there were plenty of advantages using C++ instead of plain C.

RAII, streams instead of stdio patters, compilers had collection classes for common types (string, array, ...) with bounds checking configuration,....

Re: Writing C for Curl

#56

Post by woodrowbarlow »

voidUpdate wrote: post #21
Zambyte wrote: post #19

Earlier quoted context omitted.

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

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.

Re: Writing C for Curl

#57

Post by dspillett »

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?

There are many, usually non-technical people though some devs & such too, who maximise everything then complain about how much space is wasted on the right of their fancy screen.

I have a 32" screen running at "standard" pixel pitch (matching the 24" 1080p screen I have in portrait next to it) which I sometimes use full-screen but usually have split 50/50, 33/66, 25/75, or 33/33/33, depending on what I'm doing. One of our testers doesn't understand, can't see benefit I get from the flexibility ("why not just have two monitors?" has been asked several times). It seems to actively annoy her that such a wide screen exists. If she ever saw the ultra-wide my friend uses for gaming I think she'd have a seizure.

Admittedly when sat this monitor plus the other in portrait is in total a bit wide (so the other screen is usually relegated to just being mail/chat windows that I only interact with when something pings for my attention) and a touch too tall. It is much more comfortable when I use the desk raised so I stand, which is how I work >⅔ of the time.

Re: Writing C for Curl

#58

Post by voidUpdate »

woodrowbarlow wrote: post #56
voidUpdate wrote: post #21

Earlier quoted context omitted.

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

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

Re: Writing C for Curl

#59

Post by pornel »

uecker wrote: post #22
pornel wrote: post #18

Earlier quoted context omitted.

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

Even if you rewrite C code to the same "shape" as Rust, it won't become equally easy to statically analyze. The C language doesn't give the same guarantees, so it doesn't benefit from the same restrictions. For example, pointers don't guarantee their data is always initialized, `const` doesn't make the data behind it truly immutable, and there's no Send/Sync to describe thread safety. You have nothing to express that a piece of memory has a single owner. C's type system also loses information whenever you need to use void* instead of generics, unions with a DIY tag, and have pointers with a mixed provenance/ownership.

Rust checks that you adhere to the analyzable structure, and keeps you from accidentally breaking it at every step. In C you don't get any compiler help for that. I'm not aware of any tools that guide such structure for C beyond local tweaks. It'd be theoretically possible with enough non-standard C language extensions (add borrowing, exclusive ownership with move semantics), but that would get pretty close to rewriting the code in Rust, except using a bolted-on syntax, a dumb compiler that doesn't understand it, and none of the benefits of the rest of Rust's language, tooling, and ecosystem.

Re: Writing C for Curl

#60

Post by pjc50 »

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.

> they have direct control over the generated assembly

They do not. As seen by all the "optimizer has done weird stuff" bugs.

Post reply on HN