Hacker News Reader

Comment by tayistay | Hacker News Reader

> Now C isn’t just a programming language, it’s a protocol.

But the image above that is calling conventions for functions on a particular processor. What does that have to do with C?

> So actually semantically parsing a C header is a horrible nightmare

I'm confused. It seems to me the right way to go would be to improve C such that it's more precisely specified, easier to parse, etc. Genuine question: why is that so hard? (I suspect the reasons are more institutional than technical.)

Variable declarations are syntactically weird in C, for example. And newer languages seem to have better ways (that are actually context-free). So why couldn't C be evolved toward that?

> int foo(int x, int y)

becomes

> foo(x: i32, y: i32) -> i32

and so on.

> You don’t see England trying to improve itself, do you?

I guess that's a saying I'm not familiar with. Seems to me England has improved a lot over the years.

Go easy on me, geniuses.

View on HN

> It seems to me the right way to go would be to improve C such that it's more precisely specified, easier to parse, etc. Genuine question: why is that so hard?

It's not hard to specify a language that is all those things compared to C, but then it is, ipso facto, not C.

I don't get it. At one point C changed its syntax for function arguments (significantly, I'd say), was that new language ipso facto not C?

C compilers still support old-style function argument syntax. They have to, for backwards compatibility. Plenty of actively-developed software being compiled on modern versions of the C standard still has some older functions whose signatures are written in K&R style.

So deprecate that. Start popping up warnings. Surely C has deprecated something in its lifetime, right?

It has already been deprecated for decades, but I doubt they will ever remove it. Compatibility with millions of lines of pre-existing code is simply more important than the somewhat niche concern that it makes C harder to parse.

And we’re talking about something from the premodern time of C. Changing how declarations are written now is a complete non-starter; there would be absolutely zero appetite for that, and even if the standards committee did it, everyone would just continue using compiler flags for the last version of the standard before the change happened, so compilers and parsers would have to continue supporting it anyway.

> Surely C has deprecated something

Again, deprecated yes, but the only thing I can actually think of them removing outright is the gets function, which had way more potential to cause harm than these parsing issues.

I think you are just massively overestimating the extent to which the C committee is willing to break things. The language is managed and standardized in a totally different way from things like Python.

Well, it so happens that C23 has so far been decided to remove K&R function declarations! (the "int fn() int arg1, arg2; { /*code*/ }" kind) So it's not utterly impossible for old things to get removed (though who knows if that'll change).

But C syntax really isn't the biggest problem in this. Even if you decide to write a whole new C parser for your new language, you'd still need to support the 176 ABI triples (or not work on many systems) and detect & choose which one the user's system uses. It wouldn't be hard to reduce that number by a lot if anyone actually would've tried to.

Why wouldn’t it be hard to reduce that number? Architectures do differ after all.

Architectures do differ, but there's really not a good reason to have dozens of ABIs per architecture. But that's what we have - 15 for aarch64, 9 for armv7, 27 for x86-64, etc. Most things in each set most likely do match, but there's no specification of how they do, so it's hard to consider them in a way other than just a dozen different ABIs that might as well be for different architectures.

> Well, it so happens that C23 has so far been decided to remove K&R function declarations!

Interesting! I stand corrected, then.

C23 removes K&R declaration lists.

Ok so K&R style is going to be removed (good!) as others have pointed out. The compiler could provide a tool to automatically update the function signatures, making it relatively easy to update legacy code.

Also, it seems to me that anyone who wants the best for C would want to get rid of the context-sensitive parsing. So that would include those on the standards committee. Here's hoping they can continue improving the language over time, albeit slowly.

Reply on news.ycombinator.com