Where are the fixed width floating types?

Question

What are the C standard fixed width floating point types and where are they defined?

From MISRA-C:2004, Rule 6.3:
typedefs that indicate size and signedness should be used in place of the basic numerical types.

The MISRA-C:2004, Rule 6.3 quotes that ISO (POSIX) typedefs are:

typedef          char   char_t;
typedef signed   char   int8_t;
typedef signed   short  int16_t;  
typedef signed   int    int32_t;
typedef signed   long   int64_t;
typedef unsigned char   uint8_t;
typedef unsigned short  uint16_t;
typedef unsigned int    uint32_t;
typedef unsigned long   uint64_t;
typedef          float  float32_t;
typedef          double float64_t;
typedef long     double float128_t;

At my company we are using C-99.
IAR Electronic Workbench, version 8.4

We are at MISRA-C:2004 because they voted not to upgrade MISRA, which would require create a validation test protocol and running the protocol.

Platform is ARM Cortex M running MicroCOS operating system.

Here are the detailed questions:

1. What are the typedefs for the fixed width floating point types?
2. What include file are they inside (or are they defined as default by the compiler)?

Ceasefire

Searching cppreference.com did not show fixed width types when searched for "float32_t". – Ceasefire

For C++ language, see #2525237. – Ceasefire

What exactly does MISRA-C:2004, Rule 6.3 say? I do not find the text float64_t anywhere in the .h files in a macOS SDK, and it is supposed to be POSIX-compliant. Why did you write “ISO (POSIX)”? ISO is an organization; POSIX is a standard. Being compliant with one thing ISO publishes is not the same as being compliant with POSIX. – Caught

Thomas Matthews, what are you trying to achieve with fixed width FP types, aside from fixed width? – Straitjacket

@chux-ReinstateMonica: They are trying to comply with MISRA-C:2004 rule 6.3. – Caught

Fixed-width Floating-Point Numbers in C/C++ – Rapier

@EricPostpischil I was hoping to find out from OP, hence the question was directed to Thomas Matthews. – Straitjacket

@chux-ReinstateMonica: It is clear from the question that the MISRA rule is driving this, not some direct programming need for fixed-width types. – Caught

@EricPostpischil: The goal is to remove the MISRA warning because of rule 6.3. The text is copied from our PDF from MISRA. Unfortunately, the PDF does not allow copying. The MISRA-C:2004 document shows the table and mentions POSIX as an example. – Ceasefire

@chux-ReinstateMonica: I guess the goal is to use type names that indicate the width of the variables. The integer forms we can use from stdint.h. I didn't find any keywords that showed the width of the floating points. – Ceasefire

Answer 1

C standard fixed width floating point types are not defined

• C floating point (FP) goals are designed to embrace variations and many implementations.

• MISRA FP goals are to restrict variety.

Fixed size FP types do not result in uniform bit encoding nor other consistent FP properties. They have limited usefulness in C - hence they are not part of the C standard or library.

---

Fall-back

Code could use below and a _Static_assert (since C11) or a C99 substitute.

typedef      float  float32_t;
typedef      double float64_t;
typedef long double float128_t;

_Static_assert(sizeof(float32_t)*CHAR_BIT == 32, "float 32");
_Static_assert(sizeof(float64_t)*CHAR_BIT == 64, "float 64");
_Static_assert(sizeof(float128_t)*CHAR_BIT == 128, "float 128");

---

Further notes

Compliant C may not have all 32, 64, 128 bit FP types, thus unable to define all float32_t, float64_t, float128_t.

2 different Compliant C implementations may have a 32-bit FP types, but different encoding. Compare float32 vs. CCSI resulting in different range, precision and sub-normal support.

2 different Compliant C implementations may have a 32-bit FP types with the same encoding, but different endians, even if their integer endians agree.

Rule 6.3 (advisory): typedefs that indicate size and signedness should be used in place of the basic numerical types.: that goal "helps to clarify the size of the storage" and not much else.

Rule 1.5 (advisory): Floating-point implementations should comply with a defined floating-point standard. is particularly difficult to achieve. Even if an implementation uses the same FP encoding as IEEE 754, C allows the operations enough implementation defined behavior to differ from IEE 754.

Ideally, in C, an implementation that conforms to IEEE 754 defines __STDC_IEC_559__. Yet proving and maintaining conformity is challenging enough that an implementation may forego defining __STDC_IEC_559__ as it may only be 99.999% conforming.

Straitjacket

Answer 2

What are the C standard fixed width floating point types and where are they defined?

There are none.

---

A fixed width FP type is likely insufficient for OP's higher level (unstated) goal.

If a fixed width floating point existed, it may only make for a fixed width. If would not certainly make for a fixed range, precision, encoding, etc.

If a fixed width floating point also defined encoding, portability is reduced. If will to live with that, consider instead a series of #if tests for common FP encoding characteristics and simply use float, double, long double.

Straitjacket

Update: I created my own type name (synonym) for floating point: typedef double float64_t; and this resolved the MISRA issue. So, MISRA wants POD variable type names that indicate the width of the type. – Ceasefire

Answer 3

Apparently (unofficial source), MISRA-C:2004 rule 6.3 says:

… For example, the ISO (POSIX) typedefs as shown below are recommended and are used for all basic numerical and character types in this document. For a 32-bit integer machine, these are as follows:…

This is bad phrasing. It does not mean that POSIX or any ISO standard provides these typedef declarations. It means the software conforming to MISRA, i.e., the software you are writing, should itself define these typedef names and use them.

If that is not the intended meaning of the rule, then the rule is wrong to imply these types are specified by POSIX, because float64_t does not appear in the POSIX 2008 specification. (I did not check earlier versions; I am assuming if it appeared in earlier versions, there would at least be mention of it in the POSIX 2008 version.)

Caught