15 ms·
Considering C99 for Curl
- impoppy 4y agoI don't really get why Daniel decided not to go with C99. Doesn't C99 compiler produce the same machine code for ANSI C source code? They could start writing new code in a newer standard and fixing old code in a newer standard gradually, so most of `curl` and `libcurl` source code would have slowly, but steadily transitioned to a newer standard. Or am I missing something?
- Karellen 4y ago> Doesn't C99 compiler produce the same machine code for ANSI C source code? Only if a C99 compiler is available. As the post points out: > The slowest of the “big compilers” to adopt C99 was the Microsoft Visual C++ compiler, which did not adopt it properly until 2015 and added more compliance in 2019. A large number of our users/developers are still stuck on older MSVC versions so not even all users of this compiler suite can build C99 programs even today, in late 2022. (emphasis mine)
- 0xcde4c3db 4y agoAnd that's just the "big compilers" supporting the "big platforms". If you're shipping some bespoke embedded platform where the toolchain/OS integration was custom work, you might very well never upgrade the compiler and just pick a new one when you're forced to define a new platform due to the hardware going EOL.
- leeter 4y agoI'm mixed on this personally, on one hand... I get it. Having curl on the XYZ micro controller you're using for a project is good. At the same time the only reason MSVC added c99 support was community pressure because major projects said "we don't care about MSVC anymore we're moving on"[1]. So clearly there is a correlation between vendors and versions. If the vendors don't feel pressure to support newer versions then they'll just continue to ship the garbage they've been shipping for years. I personally don't have a good answer for this. Daniel very clearly has made his decision and I'll respect that as it's not my project. [1] Also because the C++ committee ignored Herb and just forced it into later C++ revs from a library perspective.
- TylerE 4y agoHow hard would it be to do something like C99 (or whatever) > LLVM IR > C89 (auto-generated, doesn't have to be human readable) > niche compiler?
- pjmlp 4y agoThere is no reason to support C99, when C11 and C17 are supported. Naturally without the stuff that got made optional in C11, no need to spend development effort on legacy features.
- quelsolaar 4y agoMore language isnt necceseraly better. The more features a language has the harder it becomes to read. When a language gives you a lot of options, you do spend more time chosing btween options that on the problem at hand.
- impoppy 4y agoI think I can see why, I never tried C or C++, but Zig was a pleasure to learn and play around with.
- pizza234 4y agoSmaller language isn't necessarily better, either. Case in point: no booleans make a language "smaller"; result: each codebase will have their own, different, implementation.
- quelsolaar 4y agoThere is no one way to do booleans because the choice of implementation depends on what your goals are. If you value space you should pack you booleans as bits in a larger type, but if you want fast access you should use int. bool has some nice properties becaus it doesnt have multiple states of true unlike int. C gives you types that have properties but doesnt prescribe what they should be used for.
- pizza234 4y agoPacked boolean arrays are an entirely different thing; as a matter of fact they are arrays, not a primitive data type. The boolean primitive data type is a standard in modern languages. Take any language: Rust, Go, Zig... and C99 (kind of). In C89, a project may use enums. Another macros. Another ints.
- quelsolaar 4y agoYes and im saying they may have good reason to use different types because they have different requirements.
- pizza234 4y agoHe addresses this point in the article: > [...] we would have to go gently and open up for allowing new C99 features slowly > A challenge with that approach, is that it is hard to verify which features that are allowed vs used as existing tooling normally don’t have that resolution. > The question has also been asked that if we consider bumping the requirement, should we then not bump it to C11 at once instead of staying at C99? The motivation ultimately boils down to: > Ultimately, not a single person has yet been able to clearly articulate what benefits such a C flavor requirement bump would provide for the curl project
- sanxiyn 4y agoI mean, I am not a curl developer so I don't get to vote, but restricting variable scopes to loops alone sounds worthwhile to me.
- jmull 4y agoYou can still add a set of curly braces around the loop to scope variables. The syntax isn't as nice, and you have to remember to do it (maybe a linter can help with that) but it ends up more of a "nice to have".
- jmull 4y agoThe nuance from the article is that they are adopting C99, but incrementally, feature by feature, as needed.
- quelsolaar 4y agoI think this is entierly the right approach. With smaller language footprint you have easier the code is to read and you will have less issues running the code on a wide variety of platforms. Many c99 features (like Variable Length Arrays) have been proven to be less than well designed and since been made optional.
- sanxiyn 4y agoYes, VLA is bad, but declare anywhere is very desirable. curl can't move due to old MSVC, but once that is solved, it would make a lot of sense to move to C99. The post itself says "It is not a no to C99 forever".
- mananaysiempre 4y agoCaveat re VLAs: while C23 doesn’t return VLAs to mandatory status, it does require variably modified types; so no stack space footgun but still a significant complication in the type system: void foo(size_t n) { int a[n][n]; } does not have to be supported outside C99 but void bar(size_t n, void *p) { int (*pa)[n][n] = p; } has to be in both C99 and C23 (though not in C11 or C17).
- warinukraine 4y ago> Ultimately, not a single person has yet been able to clearly articulate what benefits such a C flavor requirement bump would provide for the curl project. We mostly see a risk that we all get caught in rather irrelevant discussions and changes that perhaps will not actually bring the project forward very much. Neither in features nor in quality/security.
- Karellen 4y agoThe tipping point for me would be `snprintf()` and related functions. I've found it generally more useful/memorable/readable than strncpy()/strlcpy() and other updates to the dangerous and deprecated strcpy() just for copying strings safely, never mind it's other formatting abilities. If Curl already has its own "decent and functional replacement" for `snprintf()` that's used extensively throughout the codebase, or if they just don't need that functionality (I haven't checked) then I guess that's not an issue. But that would be the big selling point as far as I'm concerned.
- tialaramex 4y agoNote that strncpy() is not intended for safety. The purpose of strncpy() is to write to fixed size data structures such as part of the filesystem where you don't want to store NUL termination on strings. Like 1980s Internet protocol features the rationale for weird things in C is more often "That's how Unix works" than "This is actually a clever safety feature".
- dizzant 4y agoIs the original intent of strncpy() germane to the GPs comment? Explicitly stating the max length to copy is an effective tool for avoiding buffer overruns, regardless of whether the designers imagined that important use case.
- tialaramex 4y agoBut the thing it does (fill out a fixed sized buffer without caring about NUL-termination) is not at all what you'd want from a safety feature. If you look at this function assuming it's a safety feature, that's a huge surprise, and indeed if you were skimming you might miss what it does because (in the context of "it's a safety feature") this is an insane choice. "Why would you do that?". Well, because it's not a safety feature. The perf cost isn't what you'd expect from a safety feature either. Suppose we have a 1MB buffer, and we strncpy "THIS" into it using n = 1024. That's just four bytes right? Nope. strncpy() will write "THIS" and then 1020 zero bytes.
- 4y ago
- bsdz 4y ago> I think there are still much better things to do and much more worthwhile efforts to spend our energy on that could actually improve the project and bring it forward. > Like improving the test suite, increasing test coverage, making sure more code is exercised by the fuzzers. I wonder if using a more recent version of C might draw in more developers willing to contribute (in a similar vein to Linux kernel introducing Rust).
- coldpie 4y agoIt seems unlikely. If you're capable of & interested in hacking on something like curl, having to put your variable declarations at the top of the block probably isn't going to be a deal-killer for you.
- cesaref 4y agoThe reasons given are reasons to stick with C89 forever. Change has risk, and there are advantages and disadvantages. If there were no advantages gained from C99, it wouldn't exist (people don't release language updates for no reason). A much more interesting question is if you were writing curl today, what would you do. If the answer is still 'C89' then we as a profession have to wonder why - did we get it exactly right, and there are no lessons from the last 30 years, or is the fact there are no better alternatives deeply depressing.
- sfpotter 4y agoThe requirements for writing curl are different from the requirements for writing other software. Just because C89 is a good choice for curl doesn't mean that C99 isn't a better choice for other things. The failure isn't in having revised a language, it's in thinking that all projects using the older version must upgrade. The idea that progress is linear is an illusion.
- throwaway0x7E6 4y agosome things actually just work
- BiteCode_dev 4y agoThe question is more complicated than that: curl is so popular it is used on systems where c99 is not available. The question is how many of those exist, and are at which point it's not worth supporting them anymore.
- UncleOxidant 4y ago> curl is so popular it is used on systems where c99 is not available. What systems don't support a version gcc that compiles c99 at this point?
- BiteCode_dev 4y agoOld systems in ports and airports, military systems, anything that has a 50 years shelve life...
- josephcsible 4y ago> However, there is no longer any modern compiler around that does not support this. What features of C99 isn't this true of today?
- cesarb 4y ago> What features of C99 isn't this true of today? IIRC, MSVC stubbornly refuses to add support for variable-length arrays (which AFAIK are required for full C99 support). I don't know if there's anything else on that list of C99 features that MSVC doesn't support yet.
- xeeeeeeeeeeenu 4y ago>MSVC stubbornly refuses to add support for variable-length arrays (which AFAIK are required for full C99 support). They were made optional in C11. It was a good decision because it's a dangerous misfeature.
- uecker 4y agoI find them very useful and they often make the code cleaner. A dynamic run-time bound for a buffer can also make the code safer. VLAs are only dangerous when implemented naively (allocated on the stack without stack probing).
- xeeeeeeeeeeenu 4y ago>are only dangerous when implemented naively (allocated on the stack without stack probing). That's how it's implemented in all the major compilers. Anyway, even a hypothetical heap-based implementation would be bad because there's no way to report allocation errors.
- uecker 4y agoGCC has stack probing.
- 4y ago
- tragomaskhalos 4y ago
- deleted 4y ago[deleted]
- nine_k 4y agoThat would be a major effort, without a very clear benefit. Curl is massive, just scroll through its man page.
- sgt 4y agoI just scrolled through the man page at a speed of 15 pages per second. Aside from that, curl is an extremely important and impressive piece of software that I use daily.
- jjgreen 4y agoMassive and written in C, you'd be mad to use it ... oh curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
- fgeiger 4y agoI'll just leave this here: https://daniel.haxx.se/blog/2022/02/01/curl-with-rust/ https://daniel.haxx.se/blog/2022/02/01/curl-with-rust/
- jmull 4y agoIt's not really up to the curl people to rewrite it in rust. It's for the proponents of rust. Personally, I'm largely convinced that writing in rust will lead to safer implementations... now I'm just waiting for the full-featured, well-though-out, stable, useful rust implementations to appear. I'm not married to curl. Where's "rurl" or whatever? If it exists and does something useful as well as curl (or better), I'll happily use it.
- adql 4y agoWell, curl is a bit of swiss army chainsaw for protocols and in general there is rarely a need to have same subsystem (of "downloading/sending something to an url) have support for protocols from HTTP thru IMAP all the way to LDAP. So there is really no reason to use it Rust, use smaller, protocol-specific libs, less security problems and if you need multi-protocol support just switch by protocol and maybe write some wrappers. And for calling it from C, "Rewrite it in Rust but make ABI C compatible" means you have to repeat a lot of Curl's idiosynchracies all while recreating all of the functionality. Looking at https://curl.se/docs/security.html https://curl.se/docs/security.html there isn't that many of them that Rust safety would prevent so the real gains from that aren't probably all that great. Now OpenSSL on another hand...
- kazinator 4y agoIn C99 there are some nice things over C89 that aren't new syntax, like initializing aggregates in automatic storage ("stack") with non-constant expressions: struct point p = { getx(obj), gety(obj) }; /* C90 error, C99 OK */ GCC had this as an extension before C99. Coding around that one can get ugly, and it's just a syntactic limitation. Also, the C99 preprocessor is more powerful, with variadic support. The macros I implemented in the cppawk project (awk with C preprocessor) would be impossible without C99. I was able to make a multi-clause loop macro, with user-definable clauses. https://www.kylheku.com/cgit/cppawk/about/ https://www.kylheku.com/cgit/cppawk/about/
- krylon 4y agoIn 2007-2009, I worked a job that for most was consisted of maintaining a C89 codebase. We were using OpenWatcom, which at the time did not have complete C99 support. But in retrospect I'm surprised to see how many features we used liberally would have been unavailable in pure C89. snprintf first and foremost. But also // comments, __func__, and stdint.h
- badsectoracula 4y agoAFAIK almost all of C99 functionality was basically about standardizing features found in existing compilers prior to it.
- attah_ 4y agoDidn't Linux just switch for added safety against some speculative execution vulns? Keeping iterator variables scoped to their respective loops, it seems. Isn't cURL susceptible to this too? (Not to mention i always find that style much nicer :)
- lsllc 4y agoPreviously posted by /u/edent (not much discussion though): https://news.ycombinator.com/item?id=33636732 https://news.ycombinator.com/item?id=33636732
- warbler73 4y ago> tldr: we stick to C89 for now. Cool.
- tinglymintyfrsh 4y agoIs there any user value to changing? Probably not. Is there risk associated with changing? Probably yes in terms of security and limiting compatibility. It probably doesn't make sense to change now unless there are specific reason(s) that will lead to impactful improvements.
- gweinberg 4y agoWon't older versions of curl source code be available forever in any case? I understand that people use very old machines/code sometimes, but I don't think it's that unreasonable to say "if you must use a compiler with capabilities stuck in the 20th century, you can't use curl source newer than late 2022".
- ben0x539 4y agoFor things that touch the network and maybe particularly use TLS, sometimes people are suddenly in a hurry not to be using an old version anymore. The people with the classic compilers would probably have to be prepared to backport security fixes on short notice, I figure the curl project might not want to put them into that awkward position.
- charcircuit 4y agoopenssl doesn't support C89. If you have TLS you probably already have access to a new enough compiler.
- zinekeller 4y agocurl doesn't necessarily require OpenSSL for its TLS functions, in fact it's designed to be TLS-agnostic (to the point that it uses macOS Secure Transport API and Windows Schannel by default). You could either use wolfSSL or use a dedicated TLS code connected to the embedded cryptographic co-processor.
- charcircuit 4y agoIf you are willing to download a new curl, why can't you download a new compiler?
- andy128k 4y agoThat's how software stagnates and dies. > ... risk opening the flood gates for people rewriting things... This sounds like "we feel that changes are needed but we will not be able control it".
- pencilguin 4y ago