5 ms·
> 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
by tayistay 5y ago
> 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.
- dragonwriter 5y ago> 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.
- tayistay 5y agoI 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?
- School-Cotton 5y agoC 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.
- tayistay 5y agoSo deprecate that. Start popping up warnings. Surely C has deprecated something in its lifetime, right?
- School-Cotton 5y agoIt 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.
- dzaima 5y agoWell, 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.
- tayistay 5y agoWhy wouldn’t it be hard to reduce that number? Architectures do differ after all.