Rule 10.3, conversion from complex types to real floating types

[satoshi]

The following code can be compiled.

Code:

float f;            // sizeof(float) = 4
double d;           // sizeof(double) = 8
float _Complex fc;  // sizeof(float _Complex) = 8

d = fc;  // violate rule 10.3 ?
fc = d;  // violate rule 10.3 ?

f = fc;  // violate rule 10.3 ?
fc = f;  // OK?

The "double type" has no imaginary parts.
So, I can say "assign to narrower essential type" ?

[dg1980]

The code example also violates Directive 4.6 and Rule 1.2.
The problem with language extensions such as _Complex is, that they have no essential type in the MISRA document.
But i would imagine that f=fc is a certain violation, because the imaginary part seems to be sliced.
And d=fc and fc=d because they are essentially different.

[satoshi]

Thank you for answering.
Sorry, I had forgotten to write with the C99.

Keyword "_Bool", "long long", "_Complex" were all added in C99.
_Bool and long long are standard, but _Complex is language extension?
I do not want to think the _Complex, but there is no clear reason...

The code example also violates Directive 4.6 and Rule 1.2.
The problem with language extensions such as _Complex is, that they have no essential type in the MISRA document.

[dg1980]

Sorry, you are correct.
_Complex indeed is standardized in C99.
The basic type is identical, while the size is not (see quotes below).
So, in my opinion, the mixed assignments in your sample code could be classified as violating 10.3 because of a "narrower essential type".
Let´s wait for an official statement.

For each floating type there is a corresponding real type, which is always a real floating
type. For real floating types, it is the same type. For complex types, it is the type given
by deleting the keyword _Complex from the type name

Each complex type has the same representation and alignment requirements as an array
type containing exactly two elements of the corresponding real type; the first element is
equal to the real part, and the second element to the imaginary part, of the complex
number.

[satoshi]

Thank you.
Your explanation is convincing.

So, in my opinion, the mixed assignments in your sample code could be classified as violating 10.3 because of a "narrower essential type".

For each floating type there is a corresponding real type, which is always a real floating
type. For real floating types, it is the same type. For complex types, it is the type given
by deleting the keyword _Complex from the type name

Each complex type has the same representation and alignment requirements as an array
type containing exactly two elements of the corresponding real type; the first element is
equal to the real part, and the second element to the imaginary part, of the complex
number.

[misra-c]

When a value of complex floating type is converted to a real floating type, the imaginary part is discarded (C99 6.3.17(2)) and the real part is converted according to the normal C conversion rules. The normal MISRA C:2012 guidelines apply to the conversion on the real part.

Code:

d = fc;  // permitted float -> double conversion
  f = fc;  // permitted no conversion required as float to float

However the following would violate rule 10.3

Code:

double _Complex dc;
  f = dc;  // violates rule 10.3 since real part undergoes narrowing conversion.

When a value of real floating type is converted to a complex floating type, the imaginary part is given the value of 0 (C99 6.3.17(1)) and the real part is converted according to the normal C conversion rules. The normal MISRA C:2012 guidelines apply to the conversion on the real part.

Code:

fc = d;  // violates rule 10.3 since real part undergoes narrowing conversion.
   fc = f;  // permitted no conversion required as float to float

More discussion on MISRA C:2012 handling of complex types can be found at http://www.misra.org.uk/forum/viewtopic.php?t=1273

[misra-c]

Support for _Complex was added my MISRA C:2012 Amendment 3, and incorporated into MISRA C:2023