Hacker News Reader

Comment by impoppy | Hacker News Reader

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

View on HN

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

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

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

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

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

He 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

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

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

The nuance from the article is that they are adopting C99, but incrementally, feature by feature, as needed.

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

I think I can see why, I never tried C or C++, but Zig was a pleasure to learn and play around with.

Smaller language isn't necessarily better, either. Case in point: no booleans make a language "smaller"; result: each codebase will have their own, different, implementation.

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

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

Yes and im saying they may have good reason to use different types because they have different requirements.

Reply on news.ycombinator.com