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

["Theodore Ts'o" <tytso@mit.edu>]

On Mon, Mar 13, 2023 at 12:00:04PM -0400, Paul Winalski wrote:
> 
> 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.

It's worse than that.  Programming language stanrds committees are
dominated by engineers working on compilers, and there are very few (I
personally know of only one) OS engineers who might be trying to *use*
the language in a kernel where you have interrupt handlers, etc., and
don't like the fact that the compiler might optimize the code in such
a way that it moves instructions out from a critical region, etc.

> 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.

For a sufficiently important program, it's possible for the authors to
say --- the C standard is just ***insane*** and if you want us to
support compilation of say, the Linux kernel by your compiler, you
*must* provide knobs to turn off certain insane "features" of the C
language spec.  GCC and Clang have those knobs, so you could say that
it they support the Linux kernel "dialect".  And the fact that this
dialect isn't blessed by the ISO committee doesn't cause me to lose
any sleep at night.

> 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.

Compiler companies who are playing benchmark wars care about execution
speed --- of benchmark programs.  I'm not sure how many programmers
actually care about some of these optimizations, because there aren't
*that* many programs that are really CPU bound, and many which appear
to be CPU bound are often hitting memory bandwidth / caching issues,
which are not necessarily the things which tricky compiler
optimizations can fix.

As an OS engineer, I deeply despise these optimization tricks, since I
personally I care about correctness and not corrupting user data far
more than I care about execution speed ---- especially when the parts
of the kernel I work on tend not to be CPU bound in the first place.

	    	     	     	      	 - Ted