GCC 13 Supports New C2x Features, Including Nullptr, Enhanced Enumerations

https://www.infoq.com/news/2023/05/gcc13-c2x-features/

by mikece • 3 years ago

125 101 3 years ago

infoq.com

jwilk• 3 years ago

https://news.ycombinator.com/item?id=35813821 ("New C features in GCC 13", 11 days ago, >260 comments)

zabzonk2• 3 years ago

nullptr is since c++11

https://en.cppreference.com/w/cpp/language/nullptr

sorry - thought the post was re c++ - my bad

mananaysiempre5• 3 years ago

In C++. C only copied it in C23 (not yet ratified).

zabzonk2• 3 years ago

sorry, misread the post

cjensen• 3 years ago

nullptr has been such a Godsend for C++. Good to see it coming to C.

If you ever see the macro NULL in code, be afraid. There are two valid ways of defining the macro and that cause weird issues when porting code. For example, in the statement printf ("%p %s\n", NULL, "Hello world!"), one of the definitions leads to NULL being interpreted as the null pointer, and the other leads to NULL being interpreted as an integer. The latter may crash if integer and pointer are different sizes.

It also causes problems with C++ overloading if one overload takes a pointer and another takes an integer.

LordShredda• 3 years ago

But does C need a nullptr keyword? If you're programming in C, you usually define 0 as an invalid value, or a null value. C doesn't have the insane type system C++ has and doesn't have a very strong need to make a distinction between a pointer or an integer, since they're all in the end numbers.

The printf example you gave is an example of garbage in, garbage out. If NULL is a macro not defined as a pointer sized integer, then you're at fault here.

LegionMammal9784• 3 years ago

Well, the fault depends on who "you" are: the NULL macro generally comes from one's libc, and allegedly some libc maintainers have been very obstinately against changing their NULL macros to have pointer type.

throwway120385• 3 years ago

Aren't there platforms where pointers have additional type or space information encoded that is orthogonal to the numeric address? It's only by convention that NULL == 0 because on platforms like Intel & ARM you would typically not use the first page. But that's only a convention, and you could just as easily put a null page at the top of your address space, especially in systems with an MMU where mappings can be added, removed, or remapped as-needed.

mananaysiempre5• 3 years ago

If NULL is a macro not defined as a pointer sized integer, then you're at fault here.

If it was you who wrote stdlib.h, sure; otherwise, if you’re on a platform where NULL is traditionally defined as 0 and not (void *)0, you’re stuck. A conformant implementation is free to use either definition.

If you want to language-lawyer more heavily, C does not require there to be pointer-sized integers (uintptr_t is optional), does not require that all zero bytes represent a null pointer in memory (unlike for integers), does not require that the implementation choose to store an integer with value zero as all zero bytes (there may be other valid representations), and in any case does not require an implementation to do anything reasonable at all if the caller passes an integer but a vararg callee looks for a pointer (think separate integer and pointer registers).

[I’m not entirely sure if (void *)(void *)0 is a null pointer constant (though it’s certainly an expression that evaluates to a null pointer)—does it count as a zero-valued integer constant expression cast to a pointer to void? So you might not even be able to use (void *)NULL as a hedge against bad platform headers.]

kevin_thibedeau4• 3 years ago

0 never should have been overloaded in C to refer to the NULL pointer. With pointer assignment and comparison it transforms to the platform's encoding for NULL which isn't necessarily all zeros. No other literal has this sort of magic.

bluGill3• 3 years ago

Assuming 0 is an invalid value is not always correct. 0 is a perfectly valid pointer, and making it impossible to refer to that location is bad. Of course if you are not writing an OS or embedded system you won't ever have a pointer value of 0 anyway as the OS can put things elsewhere with no problem (if you are you need to see your CPU docs, some CPUs 0 is invalid, some it is not).

roqi2• 3 years ago

But does C need a nullptr keyword?

Yes, it does.

If you're programming in C, you usually define 0 as an invalid value, or a null value.

That was also the usual pattern in C++ when there was no alternative. Once nullptr was introduced in C++, NULL or 0 quickly became a code smell.

C doesn't have the insane type system C++ has and doesn't have a very strong need to make a distinction between a pointer or an integer, since they're all in the end numbers.

C++'s type system is far from insane. It's actually one of it's killer features.

You're both entirely oblivious to the need to not conflate pointers with integers and failing to present any case in favour of the legacy and broken use of NULL, and in the process failing to address all family of known error patterns involving it.

The printf example you gave is an example of garbage in, garbage out. If NULL is a macro not defined as a pointer sized integer, then you're at fault here.

Again, you seem to be completely oblivious to the problem domain. NULL is not a macro as far as C or C++ compilers are concerned. NULL is a magic constant that's resolved at preprocessing time. Replacing NULL with nullptr means a magic constant is replaced by a concrete type, and thus whole family of errors can be avoided with compile time checks. Claiming that the developers who wrote in bugs are at fault for inadvertently adding bugs makes no sense at all because it does not solve any problem at all, and instead is just cynical finger pointing. I take compile-time checks over unhelpful finger pointing all day every day.

josefx• 3 years ago

The latter may crash if integer and pointer are different sizes.

Apparently some compilers specified a special __null extension to handle that case before nullptr was a thing.

kazinator12• 3 years ago

Since NULL expands to an implementation-defined null pointer constant, it is valid for those implementations to go as far as #define NULL __null.

kazinator12• 3 years ago

The problems are that:

- NULL is idiomatic: using NULL is entrenched in C programming and it is not going away.

- In spite of nullptr existing now, NULL is still (quite stupidly) not required to just expand to nullptr, but to an implementation-defined null pointer constant, rather than #define NULL nullptr. (According to the N2596 draft).

- They had over 30 years to tighten the requirements on how NULL can be defined; what's the matter? C99 could already have required NULL to be ((void *) X) where X is an integer-typed constant expression evaluating to zero.

I'm not going to start using nullptr. It's not idiomatic C. I'm going to hold out hope that NULL will be fixed so that it expands to nullptr.

Also, it's possible for a compiler to diagnose when a constant, zero-valued expression is used as the argument of a variadic function. The diagnostic can be confined to cases when such a constant expression is the result of macro expansion:

  printf_like_function("fmt ...", ... 0, ...);  // OK

  #define FOO 0

  printf_like_function("fmt ...", ... FOO, ...);  // compiler diagnostic

  printf_like_function("fmt ...", ... (int) FOO, ...); // OK

bigbillheck2• 3 years ago

NULL is idiomatic

It is today, but idioms are a human concept and who knows how things will be in 2033?

pjmlp3• 3 years ago

Once upon a time K&R C function declarations were idiomatic, in C23 they are out.

cogman10• 3 years ago

In spite of nullptr existing now, NULL is still (quite stupidly) not required to just expand to nullptr, but to an implementation-defined null pointer constant, rather than #define NULL nullptr. (According to the N2596 draft).

This is so silly. I sort of get why not (can't break the dork that decided to do

    int i = NULL;
    i++;

)

But, at the same time... I almost feel like this is a "you are being a dork, go fix your code." moment. This isn't the sort of break where someone would see it and go "Oh yeah, assuming NULL is anything other than nullptr is dumb!"

ori_b4• 3 years ago

If you ever see the macro NULL in code, be afraid. There are two valid ways of defining the macro

Not on a Posix system, where the only valid definition of it is `(void*)0`. C could have adopted this definition.

Nullptr is needed in C++ because `0` is the only definition of `NULL` that works with the type system, due to the lack of implicit `void*` conversions.

C doesn't have this problem.

Adopting the Posix definition of NULL in the standard would have been sufficient -- and unlike `nullptr`, would have solved bugs in existing programs.

blackpill0w• 3 years ago

C doesn't have this problem

I don't think a strong type system is a `problem`, implicit conversions can lead to so many annoying and hard to find bugs.

haileys• 3 years ago

Nullptr is needed in C++ because `0` is the only definition of `NULL` that works with the type system, due to the lack of implicit `void` conversions.*
C doesn't have this problem.

Except for conversions between data pointers and function pointers ;)

Initialization seems to be a special case, but with `-pedantic` the following code will show a warning on the initialization of `fp2`:

    void* return_null() {
        return 0;
    }
    
    int main() {
        void(*fp1)() = 0;
        void(*fp2)() = return_null();
    
        return 0;
    }

whimsicalism• 3 years ago

due to the lack of implicit `void` conversions. C doesn't have this problem.

implicit void conversions are the problem

cryptonector6• 3 years ago

This proposal also recommends adoption of Unicode normalization form C (NFC) for identifiers to ensure that when compared, identifiers intended to be the same will compare as equal. Legacy encodings are generally naturally in NFC when converted to Unicode. Most tools will, by default, produce NFC tex.

Er, a much better approach is to allow unnormalized Unicode in source code and use form-insensitive matching of symbol names so that all forms of a symbol are equivalent. This can be done by normalizing during the parse, or by implementing form-insensitive string comparison and hashing functions that normalize glyph by glyph as needed -- the latter can be very fast for all-ASCII and mostly-ASCII symbols!

The reason this is a better way is that there's too many places that don't produce NFC. For example, HFS+ uses NFD, so if you cut-n-paste a file name from HFS+ into other contexts, you'll be pasting NFD unless the cut-n-paste system normalizes to NFC. Also, while it's true that input modes typically produce NFC, it's more that they produce NFC for a small subset of Unicode, not that they will normalize other forms seen on input. Using form-insensitive string comparison/hashing/matching yields a better user experience at not that much implementation cost: you're gonna need a Unicode library, and that library will need to have normalization support, so you can implement form-insensitivity.

wahern• 3 years ago

Er, a much better approach is to allow unnormalized Unicode in source code and use form-insensitive matching of symbol names so that all forms of a symbol are equivalent.

Linkers will often be blissfully unaware of Unicode or any form of localization. This was the impetus for UTF-8, so that the bulk of software which is 8-bit clean or which operates on opaque, NUL-terminated strings can continue working as-is. This can't be changed without breaking backwards ABI compatibility; therefore, it's very unlikely to change.

There are countless half-measures that could be taken, but few if any are suitable for standardization. If the history of software localization is any guide, in the face of strict, forward-looking specifications various vendors and ecosystems will likely go there own way, with the one sure thing being a failure to fully adopt or properly implement the specification.

cryptonector6• 3 years ago

Yes, the compiler should normalize symbols before writing object files, no doubt. I'm talking about the inputs though -the source files- which should not have to be normalized.

twic• 3 years ago

Who is the audience for new features in C? And who is driving stuff through the standardisation process? Is this stuff likely to make its way through to embedded toolchains? Or is this for people who are maintaining existing codebases?

hgs3• 3 years ago

Who is the audience for new features in C?

Folks like myself who use C to write system software.

Is this stuff likely to make its way through to embedded toolchains?

Embedded toolchains based on GCC or Clang will presumably see these features one day.

quesomaster90003• 3 years ago

The early adopters are usually transpilers (or code generators) which can quickly take advantage of new features without the effort of rewriting an entire codebase.

In the same way that Rust used underlying `const` attributes in LLVM (and found all the weird edge cases), and Nim used C as an intermediate as have many other lisp or object-ish languages.

nitrix• 3 years ago

Changes to the Standard usually happens as a result of defect reports (confusing details that implementation writers want clarity on) or vast enough general adoption (unifying how implementations were differently achieving the same thing).

You can read #13 of the Charter https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2086.htm

As for the audience, it's all the C developers, the open-source and commercial compiler implementations, vendors of libraries, tooling, services, learning material and everything else built in C; which is just innumerable.

Each Standard version released supersedes and obsoletes the previous versions. Intentionally, the versions are meant to be as backwards compatible as possible so that one can mix and match C89/C99/C11 codebases with minimum effort.

C has gained only a handful of features in the last 40 years. Compared to the great many things that are improved w.r.t. undefined/implementation-specific/unspecified behaviors, or removed to keep up with modern times (e.g. Trigraphs, Two's Complement integer representations, etc).

I'd say: (1) upgrading is not the spooky thing people make it out to be. Go, Rust, they all move much faster than this and have very ambitious big design ideas on their mind. (2) It's necessary to take good care of C as it, and the things built in it, will realistically outlive many of us.

cozzyd• 3 years ago

There is plenty of new C code.

pantalaimon• 3 years ago

Most embedded toolchains are ARM or RISC-V GCC these days, they get all the features.

nrclark• 3 years ago

Yes, I'd expect they will. Most embedded toolchains these days are built around GCC. So as GCC grows new features, embedded toolchains will get them too.

whatever1• 3 years ago

I wonder whether LLMs could help with smarter code optimizations, especially, since they can be context aware.

Gibbon13• 3 years ago

We should have a ten year moratorium on optimizations and force the compiler maintainers to work on other things.

quesomaster90003• 3 years ago

Nobody else is admiring typed enumerations?

Particularly when using structs this removes a lot of ambiguity if you ignore the indirection to find out the underlying type of the enum (or encode it in the name hungarian style).

    enum D : uint8_t {
        A = 0,
        B = 1,
        C = 2
    }
    typedef struct {
        D f;
    } __attribute__((packed)) E;
    assert(sizeof(E)==1);

etc. could make grokking protocol declarations with enums less onerous and requiring one less level of indirection.

maccard4• 3 years ago

I'm a c++ programmer and finding it hard to be excited about things we added to the language 12 years ago.

quesomaster90003• 3 years ago

As a D programmer, why haven't you caught up yet?

loeg2• 3 years ago

As a sneering C++ programmer, why are you even reading / commenting on a new C standard? This is basically a "if you don't have anything nice to say, don't say it" situation.

paulddraper• 3 years ago

I wouldn't speak too loudly on that high horse.

The HN Rust Gang will find you.

david2ndaccount• 3 years ago

Clang has had it as an extension for a long time

anonymousDan• 3 years ago

Are there any good resources on writing compiler optimization/instrumentation passes in gcc (as opposed to LLVM)?

xenadu022• 3 years ago

Officially adopting __auto_type as auto is good. Unfortunate that N2953 dropped function return type and parameters.

This feature composes with _Generic macros quite well:

  #define div(X,Y) _Generic((X)+(Y), int: div, long: ldiv, long long: lldiv) ((X), (Y))
  
  auto res = div(38484848448, 448484844); 
  auto a = b * res.quot + res.rem;

It also lets you get rid of all the "typeof(X)" foo in macro definitions.

typon• 3 years ago

Two uncontroversially useful C++ features (nullptr, typed enums) entering C is a great thing.

I really wish C++ had Rust style enums. Having to implement them with flags in C++ is a bit of a chore.

xenadu022• 3 years ago

For those who are wondering about lambdas and defer those were tabled to the next standard revision but not rejected.

Lambda: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2892.pdf Defer: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2895.htm

torrent• 3 years ago

Sad perspective for C programmers who need to wait 10+ years until they get half-backen versions of some useful C++ features.

GCC 13 Supports New C2x Features, Including Nullptr, Enhanced Enumerations

Related Stories