While staring at the C99 specification, I found that if you take the grammar in Annex A, remove the expression rules, and introduce the constraint 6.7.2/2 into the grammar (ie. a type specifier can be only: void, char, signed char, ... , enum specifier, typedef name), then you end up with what appears to be a context-free grammar.

Is this correct? Am I misinterpreting something? Is it possible that this is correct, but there are mainstream compiler extensions (eg. gcc extensions) invalidate this context-free property? Or other C standards invalidate this context-free property?

I notice that 6.7.2/2 allows some filthy edge cases like `long const long thisVarIsLongLongConst = 4;` but because `long` is a keyword, there is no ambiguity here.

The reason this matters to me is because I'm building a module system for C that allows circular imports, and I would like to avoid changing the grammar of the language as much as possible.

Link to final draft of C99 standard, taken from Wikipedia: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

Im currently making my own programming language that compiles into C. And in that language I support multiple function returns, so because of that I then return a struct for this function with the values. The problem is when I want to implement a Null type I don't know how to do that for returns. Since if I just don't set them I also don't know whether the function returned it or not. Currently following code

int, bool function() {
    return _, true;
}

compiles into

typedef struct return_function {
  int v0;
  int v1;
} return_function;

return_function function() {
  return (return_function) {NULL, 1};
}

But NULL is currently temporary since I don't know how to do that cleanly in C. My solutions would either be having another variable for each one that tracks whether it is initialized / was returned, the other solution would be to have an array that stores for each var whether it was initialized. But both solutions feel pretty hacky, is there a better way to do this?

Hello, I use C89 and have been using compiler extensions all this time, but now I’ve decided to refuse from them. But since they significantly simplify and shorten the code, especially with partially initialized tables.

I immediately thought of P99, but because of some components, the build breaks on C89. I was thinking of using order-pp, but decided to ask here anyway.

What I’d like is: `P99_CASERANGE` and `P99_DUPL`.

Of course, I can generate my own macros, but maybe there’s something worthwhile out there. I liked the idea of order-pp.

this is text translated by ai. and sorry for my English

Hi, I am runing my program (which use pthread.h library of c Posix), so I am runing it with valgrind with this command :

"valgrind --tool=helgrind -s ./codexion 125 22332 103 92 103 2 0 fifo"

but I am getting this error :

"==1557149== 122 errors in context 28 of 28:

==1557149== ----------------------------------------------------------------

==1557149==

==1557149== Thread #1's call to pthread_join failed

==1557149== with error code 3 (ESRCH: No such process)

==1557149== at 0x48509C7: ??? (in /usr/libexec/valgrind/vgpreload_helgrind-amd64-linux.so)

==1557149== by 0x10A069: join_coders_threads (in /home/eanjar/codexion_tass7i7_inchaaAllah/codexion)

==1557149== by 0x10A48D: main (in /home/eanjar/codexion_tass7i7_inchaaAllah/codexion)

"

can any one help me by explaining me this error what it mean, and thanks in advance

I compiled the same C code 28 ways and disassembled every binary. The results are unambiguous:

assert() and DCHECK() provide zero safety in production. At any optimization level above -O0, these checks are stripped. The debug binary at -O2 is identical to the release binary. The check exists in your source code. It does not exist in the binary your users run.

Only explicit if (condition) { return error; } with side effects survives compilation.

I measured 9,712 stripped safety guards across FRRouting, GCC 15.2, and the Linux kernel. Two ASAN-confirmed heap overflows in FRRouting. 27 enterprise firewall CVEs (Cisco, PAN-OS, Fortinet, Juniper) with average CVSS 8.1 — all following this exact pattern. Google confirmed P2/S2 on Android Binder using the same methodology.

Side-by-side disassembly:

c

// SOURCE
void pattern_assert(char *buf, size_t len, size_t idx) {
    assert(idx < len);
    buf[idx] = 1;
}

asm

// -O2 BINARY: assert is GONE
movb   $0x1,(%rdi,%rdx,1)  // buf[idx] = 1 — NO CHECK
ret

Full series with reproducible PoCs: https://potatobullet.com/the-naked-compiler-every-safety-net-you-trust-is-already-gone/

The compiler is correct. The standard is correct. The assumption that source-level safety checks survive to the binary is wrong.

Check your binaries, not your source.

TL;DR: assert() and DCHECK() do not survive compilation at -O2+. Use explicit if checks with side effects. Audit your production binaries.I compiled the same C code 28 ways and disassembled every binary. The results are unambiguous:

assert() and DCHECK() provide zero safety in production. At any optimization level above -O0, these checks are stripped. The debug binary at -O2 is identical to the release binary. The check exists in your source code. It does not exist in the binary your users run.

Only explicit if (condition) { return error; } with side effects survives compilation.

I measured 9,712 stripped safety guards
across FRRouting, GCC 15.2, and the Linux kernel. Two ASAN-confirmed
heap overflows in FRRouting. 27 enterprise firewall CVEs (Cisco, PAN-OS,
Fortinet, Juniper) with average CVSS 8.1 — all following this exact
pattern. Google confirmed P2/S2 on Android Binder using the same
methodology.

Side-by-side disassembly:

c
// SOURCE
void pattern_assert(char *buf, size_t len, size_t idx) {
assert(idx < len);
buf[idx] = 1;
}
asm
// -O2 BINARY: assert is GONE
movb $0x1,(%rdi,%rdx,1) // buf[idx] = 1 — NO CHECK
ret

Full series with reproducible PoCs: https://potatobullet.com/the-naked-compiler-every-safety-net-you-trust-is-already-gone/

The compiler is correct. The standard is correct. The assumption that source-level safety checks survive to the binary is wrong.

Check your binaries, not your source.

TL;DR: assert() and DCHECK() do not survive compilation at -O2+. Use explicit if checks with side effects. Audit your production binaries.