#4217 Invalid storage classes in compound literals go undiagnosed
1: Sample code that reproduces the problem.
void f(void)
{
(void)(typedef int){1};
}
2: Exact command used to run SDCC on this sample code.
sdcc -mz80 --std=c2y --nostdinc -S bug.c -o bug.asm
3: SDCC version tested.
SDCC 4.6.4 #17068 (Linux), tested 23 October 2026.
4: Observed and expected behaviour.
SDCC exits successfully without emitting a diagnostic. A diagnostic is required.
N3886 6.5.3.6 paragraph 4 requires the storage-class specifiers, type and initialiser to form a valid object definition at the associated scope. A typedef declaration does not define an object, so (typedef int){1} violates this constraint. The same paragraph applies the storage-class constraints to compound literals.
Reference: N3886.
5: Additional checks.
Two further forms also compile silently: (static static int){1} in block scope, and unsigned x = sizeof (register int){1}; at file scope. The duplicate static violates 6.7.2 paragraph 2; the file-scope register violates 6.9 paragraph 3, applied through 6.5.3.6 paragraph 4. Using sizeof avoids a separate address-of-register violation. The duplicate-static example is additional compound-literal evidence related to [bugs:#4184], rather than a claim that the general storage-class-combination defect is new.
All three forms compile silently on five targets in C23 and C2Y: 30 invalid checks. A block-scope (static int){1} with constant initialisation is valid and compiles silently. The nearby block-scope extern-with-initialiser, static/register combination and static nonconstant initialiser are already rejected (errors 320, 146 and 2 respectively). GCC 13.3.0 rejects the invalid samples in C2x mode, but its parser does not support every permitted C23 storage class in compound literals; the normative basis is N3886, not GCC acceptance.
Related
