#4097 Function returning a function type is accepted without a diagnostic

[Christopher Bazley]

1: Sample code that reproduces the problem.

typedef int function_type(void);

function_type returns_function(void) /* ERROR */
{
  for (;;)
    ;
}

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

./bin/sdcc -c bug.c

3: SDCC version tested

Git f68fca8a4368ece9fe93b21f2e0341282b104359, SDCC 4.6.3 #0 (Linux).

Affected in valdiag testing on mcs51, mcs51-large, mcs51-stack-auto, ds390, z80, z180, r2k, r4k, sm83, tlcs90, hc08, s08, mos6502, huc6280, stm8, f8, pdk13, pdk14, and pdk15.

4: Copy of the error message or incorrect output, or a clear description of the observed versus expected behavior.

N3886 6.9.2p3 says that a function shall not have a return type that is a function type. According to the ISO C standard, all constraint violations must be diagnosed. SDCC accepts the definition without a diagnostic.

Clang 18.1.3 and GCC 13.3.0 diagnose the constraint violation. TCC 0.9.28rc (mob 9db1105, 2026-09-26) accepts it without a diagnostic and therefore has the same bug.

[Christopher Bazley]

Attaching a candidate patch to fix this bug.

This is one of eight independent patches against SDCC commit
c8cee3a5b4656a3d7ef97ef6078c38a016a02cfb (2026-09-28).
The patches were also applied together to the baseline commit and built with the PIC14 and PIC16 ports disabled. The full device library build completed successfully. Focused valdiag testing of the eight new files passed on all 19 valdiag targets: 27 checks per target, zero failures.

make -C support/regression -j2 test-ucz80:

0 failures, 36745 tests, 6409 test cases

[Philipp Klaus Krause]

Using E_TYPE_IS_FUNCTION IMO makes for a confusing error message here:

test.c:3: error 220: 'returns_function' has function type

Well, yes, returns_function is a function, but the problem is that the return type of returns_function is a function.

While N3886 6.9.2p3 is in the section about function definitions, we should also emit an error for declarations of function-returning functions that are not definitions (like GCC does), as required by N3886 6.7.7.4p1, so maybe the checks on function definitions are not the best / only place to do such a check.

[Christopher Bazley]

Agreed. It is an unfortunate consequence of treating each constraint separately. Sorry about that. As you pointed out, I think the same flaw also affects function types whose return type is array.

I’ll revise the patch so that the constraint is checked when the function declarator/type is processed, add declaration-only coverage as well as the definition case, and use a diagnostic that specifically identifies the invalid function return type.

[Christopher Bazley]

Please find a new candidate fix attached. It introduces a new error class: E_FUNC_RETURN_FUNC. It also adds tests for declaring a function that returns a function and declaring a function that returns a pointer to a function. The check has moved from checkFunction to processFunc so that bad declarations are also diagnosed. The new implementation is more defensive because func can be null when processFunc is processing a function type without a named symbol.

Summary for 'ucz80': 0 failures, 36740 tests, 6407 test cases, 7348919 bytes, 1613716860 ticks
I also ran valdiag tests on all enabled targets with 0 failures.

[Christopher Bazley]

Actually I think testing is still deficient because there are no test cases for use of function type names that are not function declarations or definitions.

[Christopher Bazley]

Here's another version of the candidate bugfix patch that further:

• adds a call to processFuncPtr from the Bison parser for type_name, to check the type.
• adds positive and negative tests for function type names that return a pointer to a function, or simply return a function, respectively.

[Philipp Klaus Krause]

Thanks. Fixed in [r16944] via your patch.