#3952 No diagnostic message when type constraint on assignment violated

[Christopher Bazley]

1: Sample code that reproduces the problem.

float *itof(int *i)
{
    return i; // no warning
}

int main(void)
{
    int s = 0, *t;
    float *f = itof(&s);
    t = f; // no warning
    t = itof(f); // no warning
    return *f;
}

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

sdcc --std=c23 /work/bug.c

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 C23 constraints on simple assignment (6.5.17.2) say:

the left operand has atomic, qualified, or unqualified pointer type, and (considering the type
the left operand would have after lvalue conversion) both operands are pointers to qualified
or unqualified versions of compatible types, and the type pointed to by the left operand has all
the qualifiers of the type pointed to by the right operand

The specification of "compatible types" (6.7.2) says:

Two types are compatible types if they are the same

The specification of "diagnostics" (5.1.1.3) says:

A conforming implementation shall produce at least one diagnostic message (identified in an
implementation-defined manner) if a preprocessing translation unit or translation unit contains
a violation of any syntax rule or constraint, even if the behavior is also explicitly specified as
undefined or implementation-defined.

This is an oversimplification, but regardless, float and int are not the same type.
https://www.open-std.org/JTC1/SC22/WG14/www/docs/n3220.pdf

I am aware that SDCC is not a conforming implementation of C, but from a practical perspective it seems to me that diagnosing assignment/initialisation of incompatible pointer types would be of great benefit to users.

[Christopher Bazley]

By the way, it makes no difference to the behaviour of SDCC if the example is altered to prevent the optimiser from determining the return value at compile time:

float *itof(int *i)
{
    return i; // no warning
}

int main(int argc, char *argv[])
{
    int s = argc, *t;
    float *f = itof(&s);
    t = f; // no warning
    t = itof(f); // no warning
    return *f;
}

[Benedikt Freisen]

Notes:

• case '=': in decorateType in SDCCast.c calls compareType in SDCCsymt.c, but only outputs diagnostics on complete incompatibility.
• compareType in this case forwards to comparePtrType, which in turn forwards to compareType
• compareType does not appear to distinguish between explicitly and implicitly castable

Maybe we need to introduce another return value for compareType.