You have missed one important thing: every passing assertion will define a single extern function pointer with the same signature, so multiple `_Static_assert` invocations can coexist in a single scope. An extern definition doesn't have to be a function pointer by the way, I guess it helped a linker to have an easier time when removing unused symbols.

> Array to pointer decay is extremely annoying, if it was implemented as Array to "slice" decay it would be great.

It's not just annoying, it's the major source of bugs in shipped code. A fix:

https://www.digitalmars.com/articles/C-biggest-mistake.html

>Static array indices in function parameter declarations: awesome, a shame that C++ (and Tiny C) do not support it >/

The first array size is actually always decayed to a pointer, supporting it in a compiler without analysis passes like TCC is just a matter of skipping the "static" token and the size.

> Static array indices in function parameter declarations: awesome, a shame that C++ (and Tiny C) do not support it >/

C++ does?

    void print(const int (&array)[5]) {
      for(size_t i = 0; i < size; ++i)
        std::cout << array[i] << " ";
    }

Pointer decay is not a mistake.

It is what allows to do int * p = arr, and looping on array element with p++.

Keeping array type you would jump beyond the last element at first iteration.

Background: A %n format specifier in a printf call stores the number of characters written so far into a specified variable. For example:

    #include <stdio.h>
    int main(void) {
        int count;
        printf("%s%n\n", "hello, world", &count);
        printf("count = %d\n", count);
    }

    hello, world
    count = 12

%n can be exploited, but it's entirely possible to use it safely.

I'm curious about this, didn't know about %n before. What are the common pitfalls and exploits using this enables?

This is actually a pretty good list and that's why i submitted it to HN. The Chinese stratagem "Cast a Brick to attract Jade" is relevant here though i haven't yet seen much "Jade" from others :-) The author's presentation/explanation is also quite succinct and precise with references pointing to further details and thus the overall s/n ratio is very good. This is how tech stuff should be written (contrast with meandering articles with one technique being "explained" over five pages).

Knowing these sort of techniques is important because they force you to think in different ways to solve a problem which expands one's mental design space. C (and C++) is particularly important here since it is the common "lingua-franca" across all system/application software from servers to desktops to itty-bitty MCUs.

PS: Also see the book Fluent C by Christopher Preschern which while not dealing with "tricks" shows how to use C effectively using a pattern-like approach.

> `??/`, a trigraph spelling for `\`, also acted like `\` in this context.

OF COURSE it should do what \ does, otherwise you have no other way to get a \

the point of trigraphs is to allow characters to be entered that your character-set/terminal keyboard doesn't allow.

The references linked to are also a pretty good source of similar info.

Mainstream compilers agree on multicharacter literals being big endian; that is, 'AB' is usually 'A' << CHAR_BIT | 'B'. The exception is MSVC, which also works like that as long as you don't use character escapes, but if you do it emits some sort of illogical, undocumented mess that looks like an ancient implementation bug fossilized into a compatibility constraint.

The switch statement in C is not a very limited pattern match. The switch statement in C is a very ergonomic jump table. Do not think ML’s case-of with only integer literals for patterns; think FORTRAN’s computed GO TO with better syntax. And it will cease to be a WAT. (For a glimpse of the culture before pattern matching was in programmers’ collective consciousness, try the series on designing a CASE statement for Forth that ran for several issues of Forth Dimensions.)

Just think of the "case" statements like any other label, despite the misleading indentation. Then it becomes perfectly natural to jump in the middle of a loop.

This is actually pretty useful in some usecases. One very good example is Simon Tatham's "Coroutines in C" (https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html) to resume execution in a function after the point it returned from in the earlier call.

The relevant example code is;

  int function(void) {
    static int i, state = 0;
    switch (state) {
        case 0: goto LABEL0;
        case 1: goto LABEL1;
    }
    LABEL0: /* start of function */
    for (i = 0; i < 10; i++) {
        state = 1; /* so we will come back to LABEL1 */
        return i;
        LABEL1:; /* resume control straight after the return */
    }
  }

  int function(void) {
    static int i, state = 0;
    switch (state) {
        case 0: /* start of function */
        for (i = 0; i < 10; i++) {
            state = 1; /* so we will come back to "case 1"*/
            return i;
            case 1:; /* resume control straight after the return */
        }
    }
   }

This sort of thing is pretty handy sometimes. Don't forget you can have code (e.g., start of the loop) before any of the cases too!

Just turn every single IOCCC winning entry into a video, you now have a year's supply of contents.

I wonder if there's any other instance (in programming or else) of intersecting grammar constructs being accepted.

C definitly belongs into the set of WAT languages.

I'm getting the same error. This appears to be the article in question: https://github.com/Jorenar/blog/blob/gh-pages/_posts/2023-02...

I actually find the C syntax easier to read and understand.

Maybe you missed the part where this is C, you know, the language designed by many of the same people as Go but 35 years earlier.

It would be a time warp worthy of the Rocky Horror Picture Show if C's design could take syntax ideas from Go.

This... is the 1972 Riche C

It returns 2.

The only reason that might be surprising is that the "return *p;" statement refers to the value of an object at a point (textually) before its definition. But the lifetime of the object named "v" begins on entry to the innermost compound statement enclosing its definition -- in this case the body of "main".

Space for "v" is allocated on entry to "main". It's initialized to 1 when its definition is reached. The "return *p;" statement appears before the definition of "v" in the program source, but is executed after its definition was reached at run time, and within its lifetime.

It's important to remember that scope and lifetime are two different things. The scope of an identifier is the region of program text in which the identifier is visible; for "v" it extends from the definition to the closing "}". The lifetime of an object is the time span during execution in which it exists; for "v" it extends from the time when execution reaches the opening "{" to the time when execution reaches the closing "}". Formally, storage for "n" is allocated at the beginning of its lifetime and deallocated at the end of its lifetime. Compilers can and do optimize allocation and deallocation, as long as the visible behavior is consistent.

Aside: If "v" were a VLA (variable length array, introduced in C99, made optional in C11) its lifetime would begin when execution reaches its definition.

Is it 2? I'm not exactly sure though. I'm interested in hearing the logic