13 Mar
2023
13 Mar
'23
5 p.m.
On 3/13/23, Alejandro Colomar <alx.manpages(a)gmail.com> wrote:
Well, it depends on what you call "C". There are many dialects,
and I'm not sure there's any which I'd call "C".
The 3 main dialects are "ISO C", "GNU C", and "K&R C".
And then
there are subdialects of them. We could say "C" is "ISO C", since,
well, it's _the_ standard.
Note that the goal of a programming language standards committee is
very different from the goal of those who use the language. The
committee's goal is to standardize existing practice of the language
in a way that is implementable on the widest range of hardware and OS
platforms, and to provide a controlled way to add language extensions.
The goal of users is to get their job done.
The advantage of programming in strict ISO C is that the resulting
code will run just about anywhere. If you don't care about that (and
I'd wager most programmers don't) then ignore the standard.
But then, ISO C shares the aliasing
issues that GNU C has, so by avoiding the GNU C compiler you're
not avoiding the issues we're talking about; moving to a compiler
that only talks ISO C is going to keep the issues. You'll need
a compiler that talks K&R C, or some other dialect that doesn't
have aliasing issues.
As someone pointed out, the three things that most programmers value
are execution speed, execution speed, and execution speed. Aliasing
issues greatly hamper what a modern optimizing compiler can do and
still generate semantically correct code.
At that point, since you already need a subdialect of
C, GCC is
one such compiler, since it provides a comprehensive set of flags
to tune your dialect.
All the best commercial optimizing compilers do that these days. It's
a way of having your semantic cake and being able to eat it (fast
execution speed), too.
-Paul W.