Comment by astrange
3 years ago
This is not written in C if it doesn’t pass UBSan/ASan/Frama-C and co. It’s written in a language that just happens to look like C.
3 years ago
This is not written in C if it doesn’t pass UBSan/ASan/Frama-C and co. It’s written in a language that just happens to look like C.
This is incredibly pedantic, even for Hacker News. I suspect you do not wish to be responded to like this in general, so I struggle to see why it is appropriate here.
The point is that if you are programming in a C dialect or a C++ dialect you will be told this again and again.
Ask a question on Stackoverflow about code that requires nonstandard flags or uses UB. You will be told your program is not really in C/C++ and that your question makes no sense. You will be lectured on nasal demons for the nth time.
File a bug against a compiler asking the optimizers to back off using UB to subvert the intentions of the programmer and you will be told there's no way to even know the intentions of the programmer given that the standards don't apply.
So we can all move to a nomenclature where C is used loosely to indicate a family of languages, once of which happens to be standardized. I'd be happy to do that.
But let's not bait and switch, using standards pedantry to dismiss feature requests and bug reports, but then turning around and saying C/C++ is suitable for implementing runtimes of other languages when nothing can really be achieved in that space without going beyond the language spec.
And really in 2022 runtimes, JITs, GCs should be the primary use of C/C++. Many other uses (systems software, compilers, desktop apps, phone apps) are not suited for C/C++ due to security, stability, ease of development and newer languages that make more sense for these domains.
Well…the answer is that the response you get will depend. If you are familiar with the standard and how it is implemented in compilers, you will get a sense for which UBs are implicitly blessed by compilers and you can file bugs against. "I double freed a pointer and expected something reasonable to happen" is never going to get you a serious response. But if you ask something like "I tagged this pointer's bit pattern and untagged it and the pointer I got back isn't valid" you will generally be heard out. FWIW I would recommend picking a different language to write your language runtime in 2022, using it to support your new language is often a good way to invite memory unsafety bugs in your code.
It’s a valuable distinction! This is a thread about the C standard. It’s misleading to talk about projects that use a specific C compiler on a specific platform but plainly need implementation details past what’s in the standard, or even straight up violating them.
Well, yes and no. I do actually agree with your claim that Linux uses a nonstandard C because it builds with special flags and without them it would not work. But for code that just happens to have unintentional bugs that result in UB–I definitely consider that C. Code that has a gentleman's agreement with the compiler on certain UBs is straddling the line but I would still usually call it C, unless someone tried to claim that because GCC accepted something it must be part of the standard. My point really isn't that you're wrong or that this isn't useful in the right context–that's why I called it pedantic–but the difference between "we build our code with special flags and this doesn't work with any other code that is ostensibly in this language because of that" and "this works on major compilers but is not standards compliant" is kind large and I don't think you really needed to go where you did. Sort of like if you made a typo in a comment about the English language I don't go "you must be using a language other than English, because clearly this is not valid" I say you have a typo, but if you're one of the people who makes everything lowercase and doesn't use punctuation I might reasonable say "it's mostly English but I'm not sure I can really call it that without qualification".
Close enough. Will you claim the Linux kernel isn't C because it's compiled with -fno-strict-overflow and -fno-strict-aliasing ?
Yes, that’s why it only supports specific C compilers.
Anything that includes its own memory allocator (that doesn’t call malloc()) is probably not implemented in standardized C.
It’s still “C”, even if it’s a specific dialect. Vendor specific C extensions have existed forever.