On: New C features in GCC 13

[tlamponi]

> OS kernels

Many are, but Linux moved to C11 (well gnu11 I guess) since v5.18

Summary of discussion: https://lwn.net/Articles/885941/

Actual move https://git.kernel.org/linus/e8c07082a810fbb9db303a2b66b66b8...

Being able to replace

  int i;
  for (i = 0; i < foo; i++) { ... }

with

  for (int i = 0; i < foo; i++) { ... }

makes it already worthwhile.

Linus thinks so too:

  > I think the loop iterators are the biggest user-visible thing, but
  > there might be others.

Also interesting:

  > Of course, the C standard being the bunch of incompetents they are,
  > they in the process apparently made left-shifts undefined (rather than
  > implementation-defined). Christ, they keep on making the same mistakes
  > over and over. What was the definition of insanity again?

-- https://lwn.net/ml/linux-kernel/CAHk-=wicJ0VxEmnpb8=TJfkSDyt...

[astrange → tlamponi]

> Also interesting:

The issues here are:

- if it's defined, then people will rely on it, which means UBSan can't report it as an error if it sees it.

- IIRC x86 defines the overflow behavior differently for scalar and vector ints, so x86 compilers that want to do autovectorization would probably leave it undefined.

C's original sin here is that the numeric promotion rules are wrong ('unsigned short' should not promote to 'int'!) but as long as you can't fix that, you can't get rid of UB and still be performant.

[uecker → astrange]

What is wrong with promoting unsigned short to int?