#4136 Increment and decrement of nullptr_t objects go undiagnosed

[Christopher Bazley]

1: Sample code that reproduces the problem.

void f(void) { typeof_unqual(nullptr) n = nullptr; n++; }

2: Exact command used to run SDCC on this sample code.

sdcc -mz80 --std=c2y --nostdinc -S postincrement.c -o output.asm

3: SDCC version tested.

SDCC : mcs51/z80/z180/r2k/r2ka/r3ka/r4k/r5k/r6k/sm83/tlcs90/ez80/z80n/r800/ds390/TININative/ds400/hc08/s08/stm8/pdk13/pdk14/pdk15 TD- 4.6.4 #0 (Linux)
published under GNU General Public License (GPL)

Built from clean official SVN r16981 sources on Linux.

4: Observed and expected behaviour.

Every invalid example is silently accepted on all 19 C2Y configurations and
Z80 C23. Every valid control also compiles without diagnostics.

WG14 N3886,
6.5.3.5 paragraph 1 and 6.5.4.2 paragraph 1, specifies the relevant constraints.

Prefix and postfix increment/decrement require an arithmetic or pointer operand. nullptr_t is a separate scalar type, not an arithmetic or pointer type. The local object has no const qualification because typeof_unqual is used, so the problem is its type, rather than a failure to be a modifiable lvalue (see [bugs:#4130]). SDCC accepts all four operators and a parameter operand without a diagnostic. Integer and pointer increments are valid cases that were also tested.

5: Additional checks.

Compiler Explorer: SDCC trunk and GCC 16.2 side by side.
Both panes use the sample above. SDCC uses -mz80 --std=c2y; GCC uses -std=c2y -pedantic-errors -fsyntax-only. Checked 7 October 2026: GCC diagnoses the constraint violation; SDCC accepts it without diagnostics. The CE trunk build reports SDCC 4.6.4 #16974.

GCC 13.3.0 locally (-std=c2x) and GCC 16.2.0 through Compiler Explorer (x86-64, cg162, -std=c2y) diagnose every invalid case and accept every valid one. Both used -pedantic-errors -fsyntax-only. No Clang or TCC comparison was run.

Case	Expected	SDCC Z80 C2Y
postincrement.c	Invalid	Accepted silently
postdecrement.c	Invalid	Accepted silently
preincrement.c	Invalid	Accepted silently
predecrement.c	Invalid	Accepted silently
parameter-increment.c	Invalid	Accepted silently
integer-increment-control.c	Valid	Accepted silently
pointer-increment-control.c	Valid	Accepted silently

Configurations tested: MCS51 default/large/medium/stack-auto, DS390, Z80, Z180, Rabbit 2000/4000, SM83, TLCS-90, HC08, S08, STM8 default/large, PDK13/14/15, and eZ80. These are translation checks, not runtime tests.

Implementation observation: The shared INC_OP/DEC_OP branch in decorateType copies the operand type and checks constant qualification without applying the arithmetic-or-pointer type
restriction to nullptr_t.

[Christopher Bazley]

This is from the ISO C standard (draft):

6.5.3.5 Postfix increment and decrement operators
Constraints
1 The operand of the postfix increment or decrement operator shall have atomic, qualified, or unqualified arithmetic or pointer type, and shall be a modifiable lvalue.

[Christopher Bazley]

Please find a candidate bug fix patch attached. It checks the operand type before marking it as an lvalue for increment or decrement. This rejects nullptr_t and aggregate operands for both prefix and postfix forms, while retaining arithmetic and pointer operations.

All 72 expected diagnostic checks passed: eight cases on nine configurations. No crash, unexpected warning/error or missed expected diagnostic was reported. Configurations tested: Z80, STM8, STM8 large, MCS51 default, MCS51 large, MCS51 stack-auto, PDK14, S08 and Rabbit R2K.