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

71–80 of 93 posts

Re: Writing C for Curl

#71

Post by johnisgood »

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.

I use either 2 spaces or tab for indentation for most languages, and I never go beyond 80 (actually, 79). It works well for XTerm, and most utilities that I use.

For git commits, I do not go beyond ~69 characters per line, so it looks neat when I am viewing the commit history.

120 characters may be fine if I only care about coding in VSCodium, for example, so sometimes I might go above the 80 column width when I am programming Go using VSCodium, but I try to not do that, because I still use "less" and whatnot, plus I have an old 17" monitor. I do not like wide monitors, I want to be able to look at the whole screen all at once, with wide monitors I would either have to be too far away, or move my head / neck / eyes too often.

So... my fonts are small, I limit to 80 column width, and I am quite happy with it. :P

To each their own, although I would have issues with Java code that not only requires me to have many files open, I would have to switch back and forth files, and I would have to horizontally scroll a lot.

I hope you realize what I am trying to say, if not, I will elaborate.

Re: Writing C for Curl

#72

Post by MrMcCall »

pjc50 wrote: post #67
MrMcCall wrote: post #63

Earlier quoted context omitted.

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

I'm not at all against a new model providing a more solid foundation for a new OS, but it's not going to be garbage collected, so the most popular of the newer languages make the pickings slim indeed.

> But the ongoing CVE pressure is never going to go away.

I think there are other ways to deflect or defeat that pressure, but I have no proof or work in that direction, so I really have nothing but admittedly wild ideas.

However, one potentially promising possibility in that direction is the dawn of immutable kernels, but once again, that's just an intuition on my part, and they can likely be eventually defeated, if only by weaknesses in the underlying hardware architecture, even though newer techniques such as timing attacks should be more easily detected because they rely on being massively brute force.

The question, to me, is "Can whittling away at the inherent weaknesses reduce the vulns to a level of practical invulnerability?" I'm not hopeful that that can occur but seeing the amount of work a complete reimplementation would require, it may simply be the best approach to choose from a cost-benefit analysis perspective where having far fewer bugs and vulns is more feasible than guaranteed perfection. And, once again, such perfection would require the hardware architecture be co-developed with the OS and its language to really create a bulletproof system, IMO.

Re: Writing C for Curl

#73

Post by kllrnohj »

MrMcCall wrote: post #65
kllrnohj wrote: post #51

Earlier quoted context omitted.

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

C++ is very definitely not just wrappers around C and it's pretty ridiculous to frame it like that. Or if you want to insist on that, then C doesn't exist, either, as it's just a few small abstractions over assembly.

Re: Writing C for Curl

#74

Post by neonsunset »

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…

> I'd like everything to be F# with native compilation

This already works today (even with GUI applications) - just define non-unbound-reflection using replacements for printfn (2 LOC) and you're good to go: dotnet publish /p:PublishAot=true

To be clear, in .NET, both JIT runtime and ILC (IL AOT Compiler) drive the same back-end. The compiler itself is called RyuJIT but it really serves all kinds of scenarios today.

> makes F# a poor choice for producing the kinds of precise abstractions needed for an OS

You can do this in F# since it has access to all the same attributes for fine-grained memory layout and marshalling control C# does, but the experience of using C# for this is better (it is also, in general, better than using C). There are a couple areas where F# is less convenient to use than C# - it lacks C#'s lifetime analysis for refs and ref structs and its pattern matching does not work on spans and, again, is problematic with ref structs.

Re: Writing C for Curl

#75

Post by Zambyte »

shepmaster wrote: post #52
Zambyte wrote: post #39

Earlier quoted context omitted.

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.

Traits encourage the same programming style, regardless of if it's technically inheritance or not.

Re: Writing C for Curl

#76

Post by creatonez »

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…

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

To be fair, this is more doable in C than most other languages. No namespacing, no generics, etc. means you're not using as many columns.

I'm still not convinced, though. It's a crunch. Would rather just set a 120 to 160 column limit and make identifiers as descriptive as they should be. And I'd use prefix namespacing all over the place anyways -- fuzzy autocomplete can make it convenient.

Re: Writing C for Curl

#77

Post by sgarland »

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.

Pointers are not a difficult concept.

Re: Writing C for Curl

#78

Post by uecker »

pornel wrote: post #59
uecker wrote: post #22

Earlier quoted context omitted.

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…

You do not get the same automatic guarantees when not using external tools. But you get almost the same results when using tools readily available and having a good strategy for organizing. I do not have problems with double frees, void type unsafety, or tagged unions in my code. I occasionally have memory leaks, which tooling then tends to find. I certainly have exploitable integer overflows, but those are easily and comprehensively mitigated by UBsan.

Re: Writing C for Curl

#79

Post by uecker »

GTP wrote: post #35
uecker wrote: post #22

Earlier quoted context omitted.

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…

> If it is acceptable to structure the code in specific ways to make the Rust compiler happy I think this is a misleading way of presenting the issue. In Rust, there are class of bugs that no valid Rust code can have (unless maybe when using the "unsafe" keyword), while there is valid C code that has said bugs. And here's the difference: in Rust the compiler prevents some mistakes for you, while in C it is you that h…

The point was that you can not reject warnings as part of a solution for C because "it annoys programmers because it has false positives" while accepting Rust's borrow checker as a solution.

Re: Writing C for Curl

#80

Post by uecker »

kpcyrd wrote: post #54
uecker wrote: post #25

Earlier quoted context omitted.

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.

I already mentioned model checkers one option. There are also other memory safe languages besides Rust. Whether an existing tool finds a bug in an existing C code is a different question though. I would have expected a double close to be found by GCC's analyzer, but I haven't tried for this particular bug (in simple cases it certainly find s it: https://godbolt.org/z/rzr9zT619). In general, it these tools find bugs more easily in well written C code, but do not help much when code is convoluted. But not writing convoluted code is more important than the choice of programming language anyway.
Post reply on HN