Yes, they should be on, in fact GCC should not do this, 'extensions' to a language that invite undefined behavior are not in line with solid software development practices. Neither is brainfuck...
I feel obliged to point out that some of those extensions a) are pretty important for large scale projects, and b) end up standardized later on anyway— eg variadic macros being added in C99.
Definitely a case to be made that the default behaviour should be what the standard says, with extensions as an opt-in. But experimental extensions also move the language forward.
Variadic macros are a special form of footgun. It is a footgun disguised as a massage device to trick you into pointing it at your foot. It also comes with an auto-trigger that will keep on shooting until the magazine is empty.
I've used them with great care and still got burned. But they are useful. The bigger issue is that they are work-arounds for things that really should have been in the language proper.
I guess what jacquesm was getting at was that instead of extending C, the world should have left C behind a long time ago and transitioned to other, safer languages.
These days there are excellent alternatives to C, but of course we also have vast codebases written in C that would be too big of an undertaking and too much of a risk to rewrite in a safer language.
There may not have been any sufficiently widespread alternative in the past in terms of developer mindshare, and sufficiently performant considering how limited the hardware was in terms of both speed and memory and storage. There is also the issue of portability and of embedded platforms, and that remains problematic to this day in some cases but in other cases the possibilities for using safer languages are already really good.
Even in cases where an alternative was known and suitable, people in the past had legacy codebases that they were working with too that they didn't want to risk rewriting in any other language. So they just kept adding to the code that they had.
The legacy-code that we are sitting on now is so many lines of code that one might wonder, was it even justified that they didn't want to take on the risk of rewriting the code in the past, while there still was a chance to do it all in one go? Maybe, maybe not.
Either way, we can do nothing about the past, but if we keep growing the legacy codebases, the problem only gets bigger in the future.
We should not strive to rewrite it all at once, but we should use safer languages when we extend our codebases, and we should use safer languages when we start new projects.
Every line of code that we write today adds to the amount of code that will make up the legacy code of tomorrow.
Let's strive to make the legacy code of the future safer, so that our children may run their societies on safer software!
I'm somewhere in the middle. I love my C compiler. At the same time I recognize the limitations of a lanuage that is now well in it's 5th decade.
The problem is that we have so much tooling and of such high quality that it is hard to switch to anything else. For myself mostly because of habit, existing libraries and speed of compilation. The edit-compile-test cycle length is a very high factor in my productivity. Go would score high on that list, other languages not so good. The stuff I do is for myself for the most part so I don't particularly care about security but in an environment where security is important with my present day knowledge of the pitfalls of C it would likely be the last language I would pick, and that is including the recognition that there are far more ways to create security holes than just memory safety, something proponents of other languages sometimes overlook.
C is a very sharp knife, it allows you to cut your fingers off in a very smooth and painless way. You'll likely realize it when you faint from bloodloss. At the same time, it is still, in spite of all those shortcomings my usual tool of choice. Simple, no huge superstructure, no whole eco system and mountains of dependencies rammed down my throat when I don't need them.
> in an environment where security is important with my present day knowledge of the pitfalls of C it would likely be the last language I would pick
Note however that even the those languages promoted as "safer" and "better" at the end typically use the C implementations of cryptographic routines (or avoid their own "safe" rules exactly when producing such a code which then ends up being "just C in disguise"). I see then some "wrappers" but at the end... it's still C (or assembly) that does the job. As far as I'm aware, nobody managed to produce both the "safety" and everything else necessary to the point to be the "best" solution for real-life use cases.
> or avoid their own "safe" rules exactly when producing such a code which then ends up being "just C in disguise"
The point with being able to do this though is that sometimes you really do need to use unsafe code, but you still get to isolate the unsafe parts of your codebase from the safe parts of it, and you do so in a way that is defined by the language itself rather than in an ad-hoc way.
The language and the compiler enforces safety for the rest of your codebase, which in most cases makes up the vast majority of the codebase, and for the unsafe parts of the codebase where it doesn’t, you have a much more limited and clearly defined surface of code that you and everyone else looking at the code will know that needs to be handled with extra care, and which can and should be audited extra thoroughly.
And in the specific case of cryptographically secure code, you may well need to be paying attention to extremely low level details like the number of instructions being executed on different branches, the states of various buffers and caches, etc. It may well be that it doesn't make sense to expose control over these things to the high level layer where it's irrelevant 99% of the time.
I bet that's almost entirely based on preferring the devil you know. Trying to write C without side channels is a ridiculously fragile affair. Many high level languages aren't suited to it, but that doesn't mean C is suited to it. Nobody should be using C for that kind of code either. Assembly maybe. The good answer is a language that can handle arrays safely and also make guarantees about what's actually executed.
ISO C is so restrictive ;)