New C features in GCC 13 (Red Hat Developer) [LWN.net]

New C features in GCC 13 (Red Hat Developer)

Posted May 4, 2023 19:31 UTC (Thu) by bartoc (guest, #124262) [Link] (18 responses)

Nullptr is probably the least exciting new feature mentioned! Also included is "auto" (which works like the existing __auto_type), explicit types for enumerations, and constexpr.

New C features in GCC 13 (Red Hat Developer)

Posted May 4, 2023 19:48 UTC (Thu) by kreijack (guest, #43513) [Link] (7 responses)

I agree, 'auto' is one of the more interesting new feature.

Another interesting thing that I hope to be standardized is the GCC[*] __attribute__((cleanup)) will be standardized (with a better syntax).

[*] However IIRC also clang has the same attribute.

New C features in GCC 13 (Red Hat Developer)

Posted May 4, 2023 19:56 UTC (Thu) by mpolacek (guest, #66426) [Link] (6 responses)

There actually is a proposal for a feature along the lines of __attribute__((cleanup)): N2895.

New C features in GCC 13 (Red Hat Developer)

Posted May 4, 2023 21:04 UTC (Thu) by mss (subscriber, #138799) [Link] (5 responses)

There actually is a proposal for a feature along the lines of __attribute__((cleanup))
Shame that the defer feature didn't make C23 - neither did its dependency of lambda functions.

While having lambda functions support in the language just save some typing when implementing callbacks, having the defer feature would allow implementing pseudo-RAII in a standard complaint way - so it would be an important improvement.

Without that standard support current implementations, like Glib's g_autoptr(), have to resort to per-compiler extensions like the aforementioned GCC's attribute.

In general, I think it's very good that, as the article says, these proposals align the C and C++ languages a little bit closer to each other by entwining certain features, and make programming in C easier and more secure.

New C features in GCC 13 (Red Hat Developer)

Posted May 5, 2023 4:09 UTC (Fri) by alison (subscriber, #63752) [Link]

> having the defer feature would allow implementing pseudo-RAII in a standard complaint way - so it would be an important improvement.

CppCast Episode 297 had a great interview with JeanHeyd Meneide called "Defer is better than destructors" in which they wax eloquent on this topic. Meneide also says that defer and lambdas would make writing a C container library possible.

New C features in GCC 13 (Red Hat Developer)

Posted May 5, 2023 22:36 UTC (Fri) by bartoc (guest, #124262) [Link] (3 responses)

interestingly GCC actually _does_ support lambda functions as an extension, they are extremely cursed, however. The following is valid GNU C and prints "Look at me! a: 4"

#include <stdio.h>

void bar(void (*fn)(void)) {
fn();
}

int main(void) {
int a = 4;
void (*fn)(void) = ({void fn(void) {
printf("look at me! a: %d\n", a);
} &fn;});
bar(fn);
}

This is a legitimate lambda function, and it relies on a sneaky combination of statement expressions and nested functions. Sadly using this feature will mark your stack as executable, and indeed it writes out thunk code to the stack, and executes it (the fn pointer here points to someplace on the stack).

New C features in GCC 13 (Red Hat Developer)

Posted May 6, 2023 14:08 UTC (Sat) by pebolle (guest, #35204) [Link]

That was fun code to play with, thank you!

I ended up in a rabbit hole full of GCC extensions, GCC en AS options, ELF sections, the execstack program, allow_execstack for selinux and what not. Lots of stuff I probably forget before I dive in that hole again.

(That you used "fn" for three different things - a parameter, a function and a nested function - gave me an opportunity to scratch my head quite a bit.)

New C features in GCC 13 (Red Hat Developer)

Posted May 8, 2023 6:20 UTC (Mon) by eru (subscriber, #2753) [Link] (1 responses)

Having encountered lambda in C++, I am convinced it is utter insanity to add this otherwise nice feature to a language that does not have automatic memory management. In C++ it is practically optimized for generating hard to find memory bugs. Please do not add it to C, please!

New C features in GCC 13 (Red Hat Developer)

Posted May 10, 2023 0:31 UTC (Wed) by DemiMarie (subscriber, #164188) [Link]

Rust does not have these problems, but that is because lifetime mistakes using closures are caught by the compiler.

New C features in GCC 13 (Red Hat Developer)

Posted May 4, 2023 21:13 UTC (Thu) by atai (subscriber, #10977) [Link] (1 responses)

C++ like "auto" in C?

New C features in GCC 13 (Red Hat Developer)

Posted May 5, 2023 22:37 UTC (Fri) by bartoc (guest, #124262) [Link]

yes, but it's simpler because it doesn't need to deal with all of c++'s rules around references and whatnot. Again, gcc already had this in the form of __auto_type. Typeof() is also included in c23.

New C features in GCC 13 (Red Hat Developer)

Posted May 5, 2023 9:24 UTC (Fri) by ballombe (subscriber, #9523) [Link] (7 responses)

On the other the addition of new keywords is very worrying. This will cause code to fail to compile.
This will cause macros to produce unintended behavior.
It is way too late to make this kind of change to the language.

New C features in GCC 13 (Red Hat Developer)

Posted May 5, 2023 22:21 UTC (Fri) by zev (subscriber, #88455) [Link] (1 responses)

These should only be enabled if you explicitly opt in to it via a '-std=...2x' flag, no? Which presumably existing code isn't doing, and wouldn't change to without being aware of the possibility of having to make some other adjustments...

New C features in GCC 13 (Red Hat Developer)

Posted May 8, 2023 13:23 UTC (Mon) by mpolacek (guest, #66426) [Link]

Correct, the new keywords are only enabled in C2x. We'll have to clean these up when switching to C2x.

New C features in GCC 13 (Red Hat Developer)

Posted May 5, 2023 22:39 UTC (Fri) by bartoc (guest, #124262) [Link]

These keywords are special snowflakes that can be trampled over with macros, without that being undefined behavior. Additionally, the [[noreturn]] attribute can also be spelled [[_Noreturn]] so that if you have a macro defining noreturn to _Noreturn (like the one in stdnoreturn.h) then things still work fine.

New C features in GCC 13 (Red Hat Developer)

Posted May 6, 2023 0:23 UTC (Sat) by NYKevin (subscriber, #129325) [Link] (3 responses)

auto is not a new keyword. It has been in C since at least C89 (I haven't bothered to check if it was in K&R). It's just that until now, auto was mostly useless (it specifies "automatic" storage duration as opposed to "static" duration - but that's the default behavior anyway).

Nullptr is potentially more of a problem, but if anyone was going around calling their local variables or typedefs "nullptr," they probably deserve for it to break.

New C features in GCC 13 (Red Hat Developer)

Posted May 6, 2023 18:35 UTC (Sat) by ballombe (subscriber, #9523) [Link] (2 responses)

I was speaking of
""This proposal harmonizes C and C++ further by making alignas, alignof, bool, false, static_assert, thread_local, and true ordinary keywords in C2X mode.""

New C features in GCC 13 (Red Hat Developer)

Posted May 6, 2023 23:56 UTC (Sat) by NYKevin (subscriber, #129325) [Link] (1 responses)

Frankly, most of those are probably not a good idea to use in C99 or later code anyway. I could imagine somebody doing some weird preprocessor nonsense with static_assert? But the rest strike me as very "here be dragons" sorts of names.

New C features in GCC 13 (Red Hat Developer)

Posted May 7, 2023 7:12 UTC (Sun) by epa (subscriber, #39769) [Link]

The earlier setup of defining bool, true, and false as macros was the worst of both worlds. (At least according to those more knowledgeable than me)

Personally I would much prefer they add real keywords and give a good honest build failure (which is usually trivial to fix) rather than play games with macros or cruft up the syntax with double-underscore.

New C features in GCC 13 (Red Hat Developer)

Posted May 4, 2023 21:45 UTC (Thu) by ceplm (subscriber, #41334) [Link] (21 responses)

> Consider the following:
>
> enum F : int { A = 0x8000 } f;
>
> […] Thus a better variant would be to use one of the types defined in <stdint.h>, for example:
>
> enum F : int_least32_t { A = 0x8000 } f;

I am just a stupid Pythonista, but is there anybody really who would willingly routinely use types like “int_least32_t”?

Beautiful is better than ugly!

New C features in GCC 13 (Red Hat Developer)

Posted May 5, 2023 0:56 UTC (Fri) by branden (guest, #7029) [Link] (8 responses)

Explicit is better than implicit.

With a plain "int" you get an integer of whatever size the platform feels like providing. Is it a fast int? Is it a small int? Undefined.

New C features in GCC 13 (Red Hat Developer)

Posted May 5, 2023 6:56 UTC (Fri) by mb (subscriber, #50428) [Link] (7 responses)

It's certainly not undefined.
And the fast/least types are BS. Sprinkling the code with ugly fast-types doesn't make it any faster. It just increases the likelihood of subtle bugs due to actual type size differences between platforms.
Just use fixed types like uint32_t.

New C features in GCC 13 (Red Hat Developer)

Posted May 5, 2023 9:35 UTC (Fri) by ballombe (subscriber, #9523) [Link] (5 responses)

Except there is no libc support for it (no int32abs() , no support in printf etc.) so it is difficult to use correctly.

New C features in GCC 13 (Red Hat Developer)

Posted May 5, 2023 10:03 UTC (Fri) by adobriyan (subscriber, #30858) [Link] (1 responses)

printf support exists with PRIu32 macros etc

New C features in GCC 13 (Red Hat Developer)

Posted May 5, 2023 22:40 UTC (Fri) by bartoc (guest, #124262) [Link]

I _think_ c23 actually added support for them to printf, without the horrible PRI macros.

New C features in GCC 13 (Red Hat Developer)

Posted May 5, 2023 10:05 UTC (Fri) by hkario (subscriber, #94864) [Link]

there is support for uint32_t in both printf and sscanf, it's just fugly

New C features in GCC 13 (Red Hat Developer)

Posted May 5, 2023 12:57 UTC (Fri) by HenrikH (subscriber, #31152) [Link] (1 responses)

there are imaxabs() in libc since C99 that can handle every single integer size

New C features in GCC 13 (Red Hat Developer)

Posted May 5, 2023 15:19 UTC (Fri) by magfr (subscriber, #16052) [Link]

Except those it can't handle.
intmax_t tend to get frozen when ABIs are set and afterwards they wont change even if the compiler supports wider types.

GCC on x86_64 have supported _int128 for years but glibc have not.

New C features in GCC 13 (Red Hat Developer)

Posted May 10, 2023 0:36 UTC (Wed) by DemiMarie (subscriber, #164188) [Link]

Some embedded platforms do not define all of the fixed-size integer types! For instance, some DSPs cannot access individual bytes, so char is 16 bits and uint8_t doesn’t exist. int_least8_t could be useful for documentation there.

New C features in GCC 13 (Red Hat Developer)

Posted May 5, 2023 12:08 UTC (Fri) by vadim (subscriber, #35271) [Link] (7 responses)

All of those have specific purposes, but yeah, they're not used all that often.

int32_t and the like is the usual sight when you're working with things like file formats and network protocols.

int_least32_t is means you want 32 bits if at all possible, but more is fine. This would be useful for storing large amounts of data, where you want to minimize the size, unless it can't be done. As to what kind of platform couldn't give you a 16 or 32 bit integer, I think it's mostly intended for DSPs and specialized architectures. So this probably mostly gets used for things like codecs. I've never had a reason to use these.

int_fast32_t means you need at least 32 bits, but if there's a faster bigger datatype, use that instead. On x86_64, asking for int_fast16_t gives you a 64 bit value.

These are not a great fit for something like printf and the like but I think for the most part that's not that big of a deal, as the main usage is in cases where you're just dealing with data, encoding something, etc.

New C features in GCC 13 (Red Hat Developer)

Posted May 5, 2023 12:55 UTC (Fri) by HenrikH (subscriber, #31152) [Link]

There are actually printf support albeit ugly ones, with PRId32, PRIdLEAST32 and PRIdFAST32

New C features in GCC 13 (Red Hat Developer)

Posted May 5, 2023 15:17 UTC (Fri) by adobriyan (subscriber, #30858) [Link] (5 responses)

> On x86_64, asking for int_fast16_t gives you a 64 bit value.

This is very wasteful, 16-bit arithmetic is just as fast on x86_64 as other bits.

New C features in GCC 13 (Red Hat Developer)

Posted May 5, 2023 18:31 UTC (Fri) by vadim (subscriber, #35271) [Link] (2 responses)

I think the length of the generated code is taken into account for the choice. So even if the actual arithmetic takes the same time, the code is more cache efficient.

New C features in GCC 13 (Red Hat Developer)

Posted May 6, 2023 0:51 UTC (Sat) by NYKevin (subscriber, #129325) [Link] (1 responses)

In the vast majority of real implementations, int_fastXX_t is implemented as a simple typedef, just like everything else in stdint.h. As far as most implementations are concerned, the only "real" integer types are char, short, int, long, and long long (as well as their unsigned variants). Everything else is just a typedef to one of those. This is also why the standard does not require that any of the intXX_t types exist - it might be the case that none of the five "primitive" integer types are exactly XX bits wide, and then the typedef may be omitted.

As a result, while an implementation is permitted to consider code length in deciding which type to use for int_fastXX_t, in practice the implementation must select *one* fixed width (for each int_fastXX_t type) and use it throughout the entire ABI. If you think about it, this is pretty much required anyway, because otherwise there could be no separate compilation of functions taking int_fastXX_t as an argument.

New C features in GCC 13 (Red Hat Developer)

Posted May 6, 2023 14:32 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

> the only "real" integer types are char, short, int, long, and long long (as well as their unsigned variants).

With the one exception that `char`, `signed char`, and `unsigned char` are distinct.

New C features in GCC 13 (Red Hat Developer)

Posted May 5, 2023 19:49 UTC (Fri) by joib (subscriber, #8541) [Link] (1 responses)

8 and 16 bit arithmetic can, depending on the circumstances, suffer from partial register stalls on x86(-64).

New C features in GCC 13 (Red Hat Developer)

Posted May 5, 2023 20:14 UTC (Fri) by adobriyan (subscriber, #30858) [Link]

If this is the case, then 32-bit is still better: no stalls and smaller instructions.

New C features in GCC 13 (Red Hat Developer)

Posted May 5, 2023 22:43 UTC (Fri) by bartoc (guest, #124262) [Link] (3 responses)

Note that another new C23 feature (and IMHO by far the most exciting feature in c23) is _BitInt(N) which is a type specifier (much like _Atomic(T)) that lets you just ask for a particular size of integer explicitly. The really exciting part is that such types ARE NOT SUBJECT TO INTEGER PROMOTION. I.e. a << 2, where a is _BitInt(8) produces a _BitInt(8), not an int. They _are_ subject to other conversions, just not promotions.

New C features in GCC 13 (Red Hat Developer)

Posted May 8, 2023 13:19 UTC (Mon) by mpolacek (guest, #66426) [Link]

In my article I wasn't describing what's new in C23, just what's new in GCC 13. _BitInt hasn't been implemented yet.

New C features in GCC 13 (Red Hat Developer)

Posted May 10, 2023 0:39 UTC (Wed) by DemiMarie (subscriber, #164188) [Link] (1 responses)

Can compilers start warning about not using _BitInt(N) at some point? Probably not because backwards compatibility, but it would be nice. Also Rust should get _BitInt(N).

New C features in GCC 13 (Red Hat Developer)

Posted May 10, 2023 18:03 UTC (Wed) by NYKevin (subscriber, #129325) [Link]

Rust has i128 and u128. Their attitude appears to be that you should be using something like rug[1] for wider ints than that.

(I suppose it would be nice to have e.g. 37 bit ints that wrap or saturate at 1 << 37, but IMHO that seems like a pretty niche use case. Just use min()/max() and/or the modulus operator as needed.)

[1]: https://crates.io/crates/rug

New C features in GCC 13 (Red Hat Developer)

Posted May 13, 2023 6:51 UTC (Sat) by oldtomas (guest, #72579) [Link] (1 responses)

Javascript black hole.

TFA screams at me "Sorry, you need to enable JavaScript to visit this website." (no shit: bold red letters).

"Uh, no?" me thinks. Then I had a cursory look at the javascript code they so unpolitely wanted me to execute. Surveillance capitalism at its cusp.

I'll pass and read up at gcc.gnu.org.

Sad. I used to be a fan of Redhat.

New C features in GCC 13 (Red Hat Developer)

Posted May 18, 2023 18:57 UTC (Thu) by jwilk (subscriber, #63328) [Link]

FWIW, you can read the article without JS if you disable also CSS or use reader mode.