#4223 Enumeration values without a common representable integer type are silently accepted

[Christopher Bazley]

1: Sample code that reproduces the problem.

enum E
{
  A = (-9223372036854775807LL - 1),
  B = 18446744073709551615ULL
};

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.7.3.3 paragraph 4 requires some standard or extended signed or unsigned integer type, or char, to be capable of representing all values of an enumeration without a fixed underlying type. A is the minimum signed 64-bit value and B is the maximum unsigned 64-bit value. The implemented standard integer types cannot represent both: signed long long cannot represent B, and unsigned long long cannot represent A. SDCC does not provide a wider extended integer type. Bit-precise integer types are a separate category and are not among the types permitted by this constraint.

Reference: N3886.

5: Additional checks.

The example compiles silently on five targets in C23 and C2Y: 10 invalid checks. Separate valid enumerations spanning signed long long minimum to maximum, or zero to unsigned long long maximum, compile silently on every target in both modes. Both integer literals in the invalid example are individually representable; this is not integer-literal overflow [bugs:#4127]. GCC 13.3.0 rejects the invalid example with -std=c2x -pedantic-errors -fsyntax-only and accepts the two valid enumerations.

Targets tested: Z80, MCS51, STM8, PDK14 and MOS65C02. These are compile-time checks. GCC 16.2 and Clang were not tested.