[TUHS] : C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)

[Paul Winalski]

On 3/13/23, Alejandro Colomar <alx.manpages at 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.