#3964 Qualifiers on the return type are not ignored in a function declaration

[Christopher Bazley]

1: Sample code that reproduces the problem.

const int f2(int);
volatile int f2(int);

int main(void)
{
    typeof(f2(1)) i = 3;
    i = 2;
    return i;
}

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

sdcc -c --std=c23

3: SDCC version tested (type "sdcc -v" to find it)

SDCC : mcs51/z80/z180/r2k/r2ka/r3ka/sm83/tlcs90/ez80_z80/z80n/r800/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8/pdk13/pdk14/pdk15/mos6502/mos65c02/f8 TD- 4.5.0 #15242 (Linux)

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

The output is:

<source>:2: error 91: extern definition for 'f2' mismatches with declaration.
<source>:1: error 177: previously defined here
<source>:7: error 33: Attempt to assign value to a constant variable (=)

This output is wrong because the C23 standard says (6.7.7.4 "Function declarators"):

If, in the declaration "T D1", D1 has the form
D ( parameter-type-listopt ) attribute-specifier-sequenceopt
and the type specified for ident in the declaration "T D" is "derived-declarator-type-list T", then the type specified for ident is "derived-declarator-type-list function returning the unqualified, non-atomic version of T".

See https://www.open-std.org/JTC1/SC22/WG14/www/docs/n3220.pdf

In other words, given the example program, neither the const nor the volatile qualifier should become part of the type of f2.

Since const should not become part of the type of f2, the second declaration of f2 should be compatible with the first (and volatile should likewise be ignored).

Since const should not become part of the type of f2, typeof(f2(1)) should not yield a const-qualified type; however, the type of f2 does appear to be const-qualified based on the error reported by SDCC about the assignment i = 2. (I have not attempted to determine whether the type of f2 is also erroneously volatile-qualified.)

[Benedikt Freisen]

(comment copied from a different bug ticket)

Can you retry with sdcc -c --std=c23 --stack-auto or sdcc -c --std=c23 -mz80?

The observed behavior can potentially be explained with SDCC's default settings:

For historical reasons, the default target -mmcs51 generates non-reeantrant function code, unless --stack-auto is specified. It then compares qualified function types, because it must not ignore (explicit or implicit) address space qualifiers. See also [feature-requests:#948], which addresses this unintuitiveness.

[Janko Stamenović]

Just to note that in this report:

TD- 4.5.0 #15242

is tested, which is old compared to the current state.

[Christopher Bazley]

TD- 4.5.21 #16327 has the same behaviour:

sdcc --std=c23 -c /work/bug9.c
/work/bug9.c:2: error 91: extern definition for 'f2' mismatches with declaration.
/work/bug9.c:1: error 177: previously defined here
/work/bug9.c:6: error 320: block-scope variable'i' declared extern and intialized
/work/bug9.c:7: error 33: Attempt to assign value to a constant variable (=)

SDCC : mcs51/z80/z180/r2k/r2ka/r3ka/r4k/r5k/r6k/sm83/tlcs90/ez80/z80n/r800/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8/pdk13/pdk14/pdk15/mos6502/mos65c02/f8/f8l TD- 4.5.21 #16327 (Linux)

[Christopher Bazley]

Can you retry with sdcc -c --std=c23 --stack-auto or sdcc -c --std=c23 -mz80?

No problem. I see the same error messages with both of your suggested configurations though: https://godbolt.org/z/M1eajTnWd

I expected that the answer might be something to do with address space qualifiers. Does that need to affect treatment of standard qualifiers though (or new qualifiers that have similar semantics to the standard qualifiers, like _Optional)?