CHECK_RANGE macro attempts to pass Rcomplex value to %f formatter

[MichaelChirico]

Seen as part of #6530, where an ad hoc solution to use val.r instead of val is used to unblock that PR.

AFAICT this is not strictly a bug because snprintf() is currently doing this (using val.r) implicitly:

DT=data.table(a = 1:10)
set(DT, 2L, 'a', 1+2i)
# Warning message:
# In set(DT, 2L, "a", 1 + (0+2i)) :
#   1.000000 (type 'complex') at RHS position 1 either imaginary part discarded or real part truncated (precision lost) when assigning to type 'integer' (column 1 named 'a')

set(DT, 2L, 'a', 1+3i)
# Warning message:
# In set(DT, 2L, "a", 1 + (0+3i)) :
#   1.000000 (type 'complex') at RHS position 1 either imaginary part discarded or real part truncated (precision lost) when assigning to type 'integer' (column 1 named 'a')

set(DT, 2L, 'a', 0+3i)
# Warning message:
# In set(DT, 2L, "a", 0 + (0+3i)) :
#   0.000000 (type 'complex') at RHS position 1 either imaginary part discarded or real part truncated (precision lost) when assigning to type 'integer' (column 1 named 'a')

But I believe the error message is not correct/as helpful as it could be if constructed more carefully.

[aitap]

We've been lucky that giving a struct instead of a double didn't damage the stack. On a 32-bit platform this could have crashed:

#include <stdio.h>

typedef union {
    struct {
        double r;
        double i;
    };
    double _Complex private_data_c;
} Rcomplex;


int main(void) {
        Rcomplex foo = { .r = 1, .i = 2 };
        printf("%f should be 1, %s should be 1\n", foo, "1");
}

$ gcc -m32 -o ex ex.c && ./ex
1.000000 should be 1, (null) should be 1

The standard says it's undefined behaviour because the expected and the given types don't match.