The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <>
To: Paul Winalski <>
Cc: Alejandro Colomar <>, TUHS <>
Subject: [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
Date: Mon, 13 Mar 2023 22:49:23 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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

  parent reply	other threads:[~2023-03-14  2:49 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-10 11:37 [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary Noel Chiappa
2023-03-10 11:51 ` [TUHS] Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary) Ralph Corderoy
2023-03-10 15:54 ` [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary Dan Cross
2023-03-12  7:39   ` Anthony Martin
2023-03-12 11:40     ` Dan Cross
2023-03-12 16:40       ` Paul Winalski
2023-03-13  3:25       ` John Cowan
2023-03-13 10:40         ` Alejandro Colomar (man-pages)
2023-03-13 12:19           ` Dan Cross
2023-03-13 12:43             ` [TUHS] [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary) Alejandro Colomar
2023-03-13 12:46               ` [TUHS] " Dan Cross
2023-03-13 16:00               ` Paul Winalski
2023-03-13 19:00                 ` Clem Cole
2023-03-13 19:09                   ` Larry McVoy
2023-03-13 19:17                   ` Steve Nickolas
2023-03-13 20:26                     ` Dan Cross
2023-03-13 22:25                       ` Alejandro Colomar (man-pages)
2023-03-13 19:24                   ` [TUHS] Re: [TUHS]: C dialects Luther Johnson
2023-03-13 19:38                     ` Luther Johnson
2023-03-14 19:48                     ` John Cowan
2023-03-14 19:56                       ` Joseph Holsten
2023-03-14 20:01                       ` Luther Johnson
2023-03-13 20:48                   ` [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary) Paul Winalski
2023-03-13 20:56                     ` Bakul Shah
2023-03-14  1:06                     ` Larry McVoy
2023-03-13 21:00                   ` Paul Winalski
2023-03-13 21:07                     ` Bakul Shah
2023-03-13 21:14                       ` Dan Cross
2023-03-13 22:15                         ` Dave Horsfall
2023-03-13 22:47                           ` Dave Horsfall
2023-03-14  0:23                             ` Dan Cross
2023-03-14  0:21                           ` Dan Cross
2023-03-14 13:52                             ` Chet Ramey
2023-03-14  1:27                         ` Bakul Shah
2023-03-13 21:28                       ` Paul Winalski
2023-03-14 10:04                       ` [TUHS] C dialects Ralph Corderoy
2023-03-14 20:02                         ` [TUHS] " John Cowan
2023-03-14 21:34                           ` Thomas Paulsen
2023-03-14  0:38                     ` [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary) John Cowan
2023-03-14  2:49                 ` Theodore Ts'o [this message]
2023-03-14  3:06                   ` G. Branden Robinson
2023-03-15  3:59 Noel Chiappa
2023-03-15  4:33 ` John Cowan
2023-03-16 22:50 ` Bakul Shah

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).