Workarounds for C11 _Generic()

https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/c11-generic/

by fanf2 • 3 years ago

74 53 3 years ago

chiark.greenend.org.uk

ajross4• 3 years ago

According to this the "big bug" is that... _Generic works mostly like a macro and expands code that the compiler sees. That seems like a little weak, macros have been doing this forever via a mere extra level of indirection.

So sure, "(x)->length" might not be valid syntax in all configurations the compiler might see. But "LENGTH(x)" is, e.g.:

   #if X_MIGHT_BE_MYSTRINGBUFFER
   #define LENGTH(x) ((x)->length)
   #else
   #define LENGTH(x) 0 /* anything that converts to the output type will do */
   #endif

This is a routine pattern seen everywhere in C. The Linux kernel is filled with it, e.g. field accessors or arch-specific functions that are stubbed out when not needed, etc...

Is this as clean as a full-on generic typesystem? No. But it's C, it shows a weirdness that you have to handle manually, and you do it the same way we've been doing it in C for decades. Not a new problem, doesn't need a new solution. It's C!

fanf22• 3 years ago

Macros and #ifdef do not solve the problems that _Generic is used for. _Generic is for static polymorphism, not for target or build configuration.

mostlylurks• 3 years ago

Macros are perfectly capable of static polymorphism. That is one of their primary use cases. _Generic is simply an alternative mechanism for static polymorphism, with some extra capabilities and some limitations in comparison to your typical macro.

ajross4• 3 years ago

Macros and #ifdef do not solve the problems that _Generic is used for.

No, but they solve the specific "big bug" described in the article very well. Use _Generic for what it's good for. Use macros to fill in the gaps (in this case build/preprocessor configuration differences that change the syntax used in the RHS of the generic expansion).

Again, this is C. You want fancy type systems, you know where to find them. Don't ask for them here, we don't want them.

kelnos2• 3 years ago

I think you've misunderstood the purpose of _Generic.

Your #if statement will select exactly one implementation for every single site of the use of LENGTH() in the codebase, depending on the value of X_MIGHT_BE_MYSTRINGBUFFER at compile-time.

_Generic() allows you to have both implementations available, and different implementations can be selected at the call site depending on the type of the argument passed.

sigsev_2513• 3 years ago

It's amazing how much power _Generic, typeof, typeof_unqual, auto and empty brace initializers can give to the compile time of C (that we already enjoy in C++ through templates, constexpr, auto and friends). Now, if only we had a way to write generic code in a reliable way...

nstbayless• 3 years ago

Will this work?

  define string_length(x) _Generic(x,        \
    const char *            : strlen((const char*)(const void*)x),           \
    struct MyStringBuffer * : ((const MyStringBuffer*)(const void*)x)->length)

kelnos2• 3 years ago

Heh, this was my first thought as well, and it does indeed compile and work (with GCC 12.2, anyway).

panzi• 3 years ago

Yeah, this is what I saw in some example code. Also you don't need the (void*), at least not with clang or GCC trunk on compiler explorer: https://godbolt.org/z/a8rP91dKr

Rexxar• 3 years ago

Not directly related but does some c/c++ compiler implement a combination of flags that create a sort "c with templates" version of C ?

constantcrying2• 3 years ago

Just use C++ with just templates?

jimbob45• 3 years ago

That would be my advice too. What was the point of “You don’t pay for what you don’t use” if nobody’s going to use it?

cmovq• 3 years ago

Templates are so intertwined with the C++ type system such that bringing "just templates" to C would require also bringing in a bunch of C++ features if you want templates to behave like they do in C++. Just for starters, you would need name mangling and/or function overloading.

LexiMax• 3 years ago

If C wanted a form of generics, it could likely do much better than templates. Concepts might've improved things, but I'm stuck on C++17 right now so I can't speak with experience.

sigsev_2513• 3 years ago

Currently it seems that the only possibility of getting generics in the language is generic lambdas wrapped in macros + tag compatible structs also wrapped in macros. It's fine but, skipping the preprocessor would be better.

Gibbon1• 3 years ago

I think it'd be more C like to add types as first class, tagged unions, and phat pointers.

constantcrying2• 3 years ago

The only reason I can imagine for this behaviour is that the compiler/standard writers did not want it.

Maybe C just shouldn't include generics. Especially not as part of the macro layer.

mananaysiempre2• 3 years ago

The macros in tgmath and more recently stdbit show why those could be necessary.

If you have a set of functions for addition with overflow detection, say add_overflow{i,l,ll}, and you have a pair of ptrdiff_t’s or int32_t’s or whatnot that you know are standard integer types, and you want to use the appropriate add_overflow* function, can you do it?

With _Generic you can. Without it I think you’re stuck providing separate functions for every integer typedef in the standard library and then requiring all library authors to do the same for both integer typedefs and integer-accepting functions that they define.

(_Generic is not part of the macro level, that’s why the semantic-checking issues discussed in the article even arise. The C preprocessor can still be implemented as a separate binary that doesn’t understand C itself, even in C23.)

maldev3• 3 years ago

You make it sound alot more complicated. Ignoring the library functions or stuff you can include from safe coding standard headers. You just do something like.

  BOOL AddOverflowUnsigned(BYTE* a, BYTE* b, INT32 sizea, INT32 sizeb)
  {
     BOOL IsMsb = PlatformIsMSB();
     BOOL IsLsb = PlatformIsLSB();
     
     //log error
     if(!IsMsb && !IsLsb)
       return FALSE;

     //Early out for overflow. Assuming 
     if(sizea == sizeb && PlatformIsMSB())
     {
        BOOL AMsb = (a >> ((sizea * PlatformByteSize()) - 1)) & 1;
        BOOL BMsb = (b >> ((sizeb * PlatformByteSize()) - 1)) & 1;
        if(AMSB && BMsb)
        {
           //We overflow, early out.
           return FALSE;
        }
      else if(sizea == sizeb && PlatformIsLSB())
        //Code here.

     //We add using bitwise operators so we can do it on any size.
     //SUM = A XOR B XOR CARRY, return in A
     //Impliment algo here.

     return TRUE;
  }

  int main()
  {
     UINT64 a = 69;
     UINT64 b = 420;
     if(sizeof(a) !
     return AddOverflowUnsinged(&a, &b, sizeof(a), sizeof(b));
  }

But they have this in the STD now and also all the secure coding libs have this in it's header as a basic function. There's also the easier implementation of just adding a check to see if it will overflow, rather than add in the function.

You also only have a few you can hardcode if you don't do it generic, since all will go back to the primitives of uint8, uint16 ....

quelsolaar2• 3 years ago

As a member of the WG14 I can tell you that _Generic does cause a fair bit of issues and complications in the language, and as a user of C i think _Generic is bad, because it mostly useful for confusing users about what code does so, Yes C would be better off without _Generic. Please don't use it.

sigsev_2513• 3 years ago

_Generic allows for more complex assertions in static_assert which is really useful for correctness (For example, your embedded chip vendor offers an API where uint8_t is used to transfer bytes using a protocol, so you have to assert that uint8_t is either char or unsigned char in order to prove that there will be no strict aliasing violation during pointer casting). Also, it's useful in order to implement the lengthof macro in a safe way that will not allow pointers to scalars or nullptr to be passed, but will only allow arrays, pointers to arrays and VMTs. There are even more uses of _Generic (if constexpr, compile time pattern matching, type traits, type safe formatting, macrowrappers to APIs that accept void*) that people have been using to emulate stronger typing and reject violations of the type system at compile time, I don't see how that's bad.

j16sdiz• 3 years ago

This is bad for non-compiler tools.

Without it, we can parse the preprocessed source code.

With the enhancement proposed, we need to do half the compiler's work.

In tools like IDE, we want quick (sub millisecond) feedback for most edits

ActorNightly2• 3 years ago

Generics are fine. Its useful to have some introspection into the data that compiler has. Thats the whole point of macros in the first place.

The behavior with _Generic is basically emergent behavior from implementation of macro processors. Macro replacements occur prior to actual compilation, so no compiler context exists for x, as such all code paths must be valid.

Its much easier to require the programmer typecast x in the replacement value then start trying to shoehorn the compiler context into macro processors.

Dylan168077• 3 years ago

Macro replacements occur prior to actual compilation, so no compiler context exists for x, as such all code paths must be valid.

How is it throwing an error like "invalid type argument of ‘->’" if there's no compiler context?

And why does an error like that get in the way of macro replacements?

(That might be the wrong message but the article says you at least get an equivalent.)

teo_zero3• 3 years ago

_Generic is not part of the macro level.

AlbertoGP• 3 years ago

At the bottom of the page lemonade is made:

Apart from the most obvious answer (that it’s useful for things exactly like <tgmath.h>), the best thing I’ve thought of to do with _Generic is to use it for deliberate error checking.
The annoyance in all the previous sections was that it was very hard to avoid compile errors, when we wanted our code to actually compile, run and do something useful. But if what we wanted was to provoke compile errors on a hair-trigger basis, then perhaps we could use it for that more reliably?

dottedmag• 3 years ago

Somehow C++ (and now C) standardization very often ends up with constructs that require a lot of ugly hacks in the code that uses them.

camel-cdr• 3 years ago

Tiny C compiler actually has a "bug" in not implementing the "big bug".

That is, the following expressions are cleanly compiled without any errors:

    _Generic(0, float: s/<[^>]*>/ /g, int: 1),
    _Generic(0, float: now the thing about this tcc implementaion is, int: 1),
    _Generic(0, float: that it just skips until the next comma, int: 1),
    _Generic(0, float: keeping track of parentheses nesting., int: 1),
    _Generic(0, float: [[ Suprizingly it doesnt validate which parentheses)), int: 1),
    _Generic(0, float:  {{{so this bullshit is possible))), int: 1,
             default: #else #define this is great isnt it?);

See: https://godbolt.org/z/o7jne7hWM

hgs3• 3 years ago

It sounds like the author misunderstands the purpose of _Generic. The author wants it to behave like pattern matching in ML languages, but that is not its purpose. The purpose of generic selection was to introduce function overloading [1] into C without breaking ABI compatibility.

[1] https://en.wikipedia.org/wiki/Ad_hoc_polymorphism

kazinator3• 3 years ago

I would have designed the feature like this:

  _Generic(<expr>, type1 : ( expr1 ), type2 : ( expr2 ), ... default : ( expr ))

Here, the parentheses shown in this phrase pattern are required.

The implementation would only parse and semantically analyze the expression of the matching type. For the others, the ( expr ) would be treated as a token sequence to be skipped, which has to contain valid tokens, and balancing parentheses, square brackets and braces.

E.g.

   char *p = "foo"

   _Generic(p : int : ("foo" ++ / ? ([]&xyz) { ; } ),
                char * : (p[0]))

Here, the type of p doesn't match int, and so the interior token sequence of ("foo" ++ / ? ([]&xyz) { ; } ) would just be scanned to check for balancing parentheses, brackets and braces, which allows the parser to locate the next clause in the association list.

Dylan168077• 3 years ago

That would allow you to put syntactically invalid code into the expressions, but is that a useful feature? It's not very hard to have valid syntax in a situation like this. The main issue here is type enforcement.

kazinator3• 3 years ago

but is that a useful feature?

It would solve the usability issues experienced by Simon Tatham, described in his article. For instance, if one of the clauses has x->foo, it wouldn't matter that the actual x argument in a given instance is char *, that cannot be dereferenced as x->foo.

It would be up to the programmer to test every one of the supported cases of their _Generic construct.

One way to avoid problems would be to include only cases that are used in your codebase. Before adding a new case, add a use* of your generic macro with the currently unsupported type. That should fail to build. Then, add the case. (TDD style).

The preprocessor's #ifdef allow syntactically invalid code. This is very useful; it lets you have conditional sections of code that are understood only by certain compilers due to using their extensions.

Arguments to preprocessor macros, if not planted into syntax, can be syntactic gibberish, but parentheses have to balance. You cannot invoke a macro as mac({(}) and such.

_Generic is meant to work with macros; it should have some macro-like forgiveness in it to make it as useful as possible.

In Common Lisp, the #+ and #- syntax for conditionally skipping forms is similarly defined as doing a minimal parsing for balancing parentheses and a few other details. This allows #+ to switch between implementation-specific code that includes implementation-specific read syntax that cannot be read by all implementations.

http://www.lispworks.com/documentation/lw51/CLHS/Body/02_dhq...

It works by binding *read-suppress* to true and then calling read to read the form.

reichstein2• 3 years ago

Just admit that it's pattern matching, and introduce a new variable for each match: ``` _Generic(expr0, type1 id1?: expr1, ... typeN idN?: exprN, default id0?: exprDefault ) ``` Every identifier is optional, but if you include `idX`, it gets bound to the value of `expr0` with type `typeX` in the following expression, or with the type of `expr0` for the default case.

Then you can safely refer to the value at its now-known type, even if `expr0` was not a variable to begin with.

teo_zero3• 3 years ago

The "big bug" indeed limits the possibilities of _Generic. But if you really want to abuse it beyond its intended scope, I think you can simply add some casting, and not the gimmicks with nested _Generic.

  #define length(x) _Generic(x, \
    char * : strlen((char*)(x)), \
    String * : ((String*)(x))->len \
  )

Workarounds for C11 _Generic()

Related Stories