Issue 1059: <fenv.h> types underspecified

Authors: Jay Ghiron
Date: 2026-05-15
Submitted against: C23
Status: Open
Cross-references: 1058

<fenv.h> defines three types:

The type

fenv_t

represents the entire dynamic floating-point environment.

The type

femode_t

represents the collection of dynamic floating-point control modes supported by the implementation, including the dynamic rounding direction mode.

The type

fexcept_t

represents the floating-point status flags collectively, including any status the implementation associates with the flags.

(C23 7.6.1 "Floating-point environment <fenv.h>" paragraph 6, 7, and 8.)

Unlike most other types in the standard library, there are no constraints on the possible types here beyond the general requirement that excludes qualified types. It seems unintended to allow for all of these possible types, for example const qualification does not make sense with function types. The additional type categories defined in issue 1058 will also be used in the following questions.

Question 1

Should fenv_t, fexcept_t, and femode_t be required to be object types?

Question 2

If the answer to question one is that they must be object types, should fenv_t, fexcept_t, and femode_t be required to be complete object types? All further questions assume the answer to this question is that they must be complete object types.

Question 3

Of the types fenv_t, fexcept_t, and femode_t, which should be required to be fundamentally-aligned types and which should be allowed to be over-aligned types?

Question 4

Of the types fenv_t, fexcept_t, and femode_t, which should be required to be strict types and which should be allowed to be flexible types?

Question 5

Of the types fenv_t, fexcept_t, and femode_t, which should be required to be modifiable types and which should be allowed to be unmodifiable types?

Question 6

Of the types fenv_t, fexcept_t, and femode_t, which should be required to be non-atomic types and which should be allowed to be atomic types?

Question 7

Of the types fenv_t, fexcept_t, and femode_t, which are intended to require representation-usable types and which are intended to allow representation-unusable types? Question seven from issue 1058 also applies to these types if representation-usable types are intended to be required.

Question 8

If the answer to question five is that some of those types should allow unmodifiable types, should any of them be required to not inhibit structures or unions which in either case contain them from being modifiable?

Question nine from issue 1058 may also apply to fenv_t, fexcept_t, and femode_t depending upon how the questions here are answered.