Issue 1062: Signaling NaNs in structures, unions, and standard library types

Authors: Jay Ghiron
Date: 2026-05-19
Submitted against: C23
Status: Open
Cross-references: 1050

Whether C assignment (6.5.17) (and conversion as if by assignment) to the same format is an ISO/IEC 60559 convertFormat or copy operation⁴²⁵⁾ is implementation-defined, even if <fenv.h> defines the macro FE_SNANS_ALWAYS_SIGNAL (F.2.2). If the return expression of a return statement is evaluated to the floating-point format of the return type, it is implementation-defined whether a convertFormat operation is applied to the result of the return expression.

⁴²⁵⁾Where the source and destination formats are the same, convertFormat operations differ from copy operations in that convertFormat operations raise the "invalid" floating-point exception on signaling NaN inputs and do not propagate non-canonical encodings.

(C23 F.3 "Operations" paragraph 4.)

According to this, the following may cause floating-point exceptions (assume __STDC_IEC_60559_BFP__ is defined for all of the examples):

#define __STDC_WANT_IEC_60559_EXT__
#include<math.h>
int main(){
double d;
setpayloadsig(&d,1);
double e=d;/* possible floating-point exception */
e=d;/* possible floating-point exception */
}

And it seems like this could possibly even be considered to apply to structures:

#define __STDC_WANT_IEC_60559_EXT__
#include<math.h>
struct S{double d;};
int main(){
struct S a,b;
setpayloadsig(&a.d,1);
b=a;/* possible floating-point exception */
}

However, it is less clear how this applies to unions:

#define __STDC_WANT_IEC_60559_EXT__
#include<math.h>
union U{long long i;double d;};
int main(){
union U a,b,x,y;
x.i=9218868437227405313;
y=x;/* no floating-point exception? */
setpayloadsig(&a.d,1);
b=a;/* possible floating-point exception? */
}

If the second assignment can raise a floating-point exception and the first assignment cannot raise a float-point exception, then presumably it needs to somehow keep track of the active member to know when to attempt to raise a floating-point exception (9218868437227405313 has an equivalent representation to the signaling NaN chosen here on x86).

Also mentioned in issue 1050, there does not appear to be anything preventing standard library functions from producing values that are signaling NaNs or contain signaling NaNs in either opaque types such as mbstate_t or structures with possible extra members such as struct tm:

#include<wchar.h>
int main(){
mbstate_t s={};
#define S "unspecified data"
mbrlen(S,sizeof(S),&s);
mbstate_t c=s;/* possible floating-point exception? */
}

Question 1

Can assignment involving structures which contain signaling NaNs cause floating-point exceptions?

Question 2

Can assignment involving unions which contain signaling NaNs cause floating-point exceptions?

Question 3

Can standard library functions produce signaling NaNs in either opaque types or structures with possible extra members, and can they produce indeterminate values in opaque types? This can even apply to types such as va_list:

#include<stdarg.h>
void f(va_list){}
void g(...){
va_list v;
va_start(v);
f(v);/* possible floating-point exception? */
/* also, possibly undefined behavior? */
va_end(v);
}
int main(){
g();
}

In instances of failure such as conversion failure with mbstate_t or fgetpos failing with fpos_t, perhaps it is useful to allow such results.