The committee has created an unreal language that no one can or will actually use.
\n- Dennis Ritchie (out of context)
this is an incomplete list of some incompatibilities between c as it's written in the standard and c as it exists in the real world for people who use gcc/clang + glibc/musl.
\nasmby default, gcc and clang recognize the asm keyword as an extension. this is not strictly conformant, because in standard c, asm is a valid non-reserved identifier. so code which conforms to the standard may not compile with gcc/clang with their default settings.
and like, whatever, that's fine, that's why -std exists, but 1. it's notable that compilers aren't conformant by default, and 2. why doesn't the standard just make asm a reserved word? c++ does that; i'm not sure why c doesn't.
FLT_ROUNDSthe standard specifies the FLT_ROUNDS macro in float.h as follows:
5.3.5.3.3p23:
\n\n\nThe rounding mode for floating-point addition for standard floating types is characterized by the implementation-defined value of
\nFLT_ROUNDS. Evaluation ofFLT_ROUNDScorrectly reflects any execution-time change of rounding mode through the functionfesetroundin<fenv.h>.
notably, the standard requires that the value dynamically changes with the runtime floating environment. gcc, however, always defines FLT_ROUNDS to 1 (rounds to nearest), regardless of the runtime rounding mode:
/* Addition rounds to 0: zero, 1: nearest, 2: +inf, 3: -inf, -1: unknown. */\n/* ??? This is supposed to change with calls to fesetround in <fenv.h>. */\n#undef FLT_ROUNDS\n#define FLT_ROUNDS 1\nclang defines a builtin for this (__builtin_flt_rounds()), but gcc doesn't, for some reason.
at some point in the future i'm gonna make an entire blog post dedicated to just this, because i kinda find it fascinating. but the super duper short version is this:
\nthe c standard specifies five standard pragmas to control the behavior of floating point arithmetic:
\n// added in c99:\n// switch can be ON, OFF, or DEFAULT\n#pragma STDC FP_CONTACT ON\n#pragma STDC FENV_ACCESS ON\n#pragma STDC CX_LIMITED_RANGE ON\n\n// added in c23:\n// direction can be FE_DYNAMIC, FE_DOWNWARD, FE_TONEAREST,\n// FE_TONEARESTFROMZERO, FE_TOWARDZERO, FE_UPWARD, or some\n// other implementation-defined value\n#pragma STDC FENV_ROUND FE_DYNAMIC\n#pragma STDC FENV_DEC_ROUND FE_DYNAMIC\nhowever, over 27 years after c99 was standardized, gcc still doesn't support any of the standard pragmas. they're just no-ops in gcc.
\nsome (but not all) of the functionality can be replicated with command-line flags, but those operate on the entire translation unit, whereas the pragmas can apply to individual functions and blocks.
\nclang mostly supports the c99 pragmas, but still doesn't support the c23 pragmas.
\nthere's actually so much more to say about these. i will be writing more about them at some point, but rn i don't really have the motivation cuz it's such a big thing lol
\nthe standard requires that qualifiers in function return types are discarded:
\n\n\nIf, in the declaration "
\nT D1",D1has the form\nD ( parameter-type-listopt ) attribute-specifier-sequenceopt\nand the type specified for ident in the declaration "
\nT D" is "derived-declarator-type-listT", then the type specified for ident is "derived-declarator-type-list function returning the unqualified, non-atomic version ofT". The optional attribute specifier appertains to the function type.
but clang treats them as significant:
\n\n;\n;\n\n\n | ;\n | \n\n | ;\n | \n\nthe two declarations should be identical, but clang thinks they're incompatible.
\nva_start definition on muslfor some reason, musl provides its own versions of some headers which the compiler already provides itself. one of these is stdarg.h, which is required to be supported by freestanding implementations and so is virtually guaranteed to already be provided by the compiler. but because it's provided by musl, compilers will use that header instead of the builtin one.
this is a problem because musl's header is strictly worse than the builtin header. here's how musl defines va_start:
#define va_start(v,l) __builtin_va_start(v,l)\nthis definition is incorrect, because c23 allows the second argument to be omitted. it should be defined like this:
\n#if __STDC_VERSION__ >= 202311L\n#define va_start(...) __builtin_c23_va_start(__VA_ARGS__)\n#else\n#define va_start(v,l) __builtin_va_start(v,l)\n#endif\nthe result is that, when compiling for musl, c23's single-argument va_start can't be used, even if it's supported by the compiler.
math_errhandling)this is kinda a sequel-ish to my previous post, in which i go over the math_errhandling macro, and how math error handling is done in glibc and musl (as well as how it's specified in the standard).
to summarize: math_errhandling is a macro which indicates which error-handling mechanisms are supported by math.h functions: errno (MATH_ERRNO) and/or floating-point exceptions (MATH_ERREXCEPT).
there's one thing i didn't mention in my previous post: there's one family of functions which is affected by math_errhandling but which isn't in math.h: the string to float conversion functions strtod, strtof, strtold, strtod32, strtod64, and strtod128:
7.25.2.6p12:
\n\n\nIf the correct value overflows and default rounding is in effect (7.12.2), plus or minus
\nHUGE_VAL,HUGE_VALF, orHUGE_VALLis returned (according to the return type and sign of the value); if the integer expressionmath_errhandling & MATH_ERRNOis nonzero, the integer expressionerrnoacquires the value ofERANGE; if the integer expressionmath_errhandling & MATH_ERREXCEPTis nonzero, the "overflow" floating-point exception is raised.If the result underflows (7.12.2), the functions return a value whose magnitude is no greater than the smallest normalized positive number in the return type; if the integer expression
\nmath_errhandling & MATH_ERRNOis nonzero, whethererrnoacquires the valueERANGEis implementation-defined; if the integer expressionmath_errhandling & MATH_ERREXCEPTis nonzero, whether the "underflow" floating-point exception is raised is implementation-defined.
the linux man pages for these functions literally don't mention this at all, and there actually is a reason why which i'll get to in a sec, but what the standard is saying is, if math_errhandling doesn't advertise support for errno (as is the case on musl, for instance), the string to float conversion functions don't set errno on error. furthermore, if the result underflows, the function isn't required to report an error at all.
keep in mind that the return value alone isn't enough to determine if an error occurred, so to test for overflow, you need to use one of the two error handling mechanisms.
\nhere is my attempt at a standards-blessed way of portably checking for overflow/underflow errors in the string to float functions:
\nfeclearexcept(FE_OVERFLOW | FE_UNDERFLOW);\nerrno = 0;\ndouble x = strtod(s, nullptr);\nbool errored = math_errhandling & MATH_ERRNO\n\t? errno == ERANGE\n\t: fetestexcept(FE_OVERFLOW | FE_UNDERFLOW);\nnote that this still doesn't guarantee that underflow is detected, since reporting underflow is entirely optional for the implementation.
\nthe reason you've never done this ever (and the reason the man pages don't mention this) is that posix specifies the functions differently:
\n\n\nIf the correct value is outside the range of representable values, ±HUGE_VAL, ±HUGE_VALF, or ±HUGE_VALL shall be returned (according to the sign of the value), and
\nerrnoshall be set to[ERANGE].If the correct value would cause an underflow, a value whose magnitude is no greater than the smallest normalized positive number in the return type shall be returned and
\nerrnoset to[ERANGE].
so posix doesn't give a shit about math_errhandling; it always requires the implementation to set errno if overflow or underflow occurs. while it's not uncommon for posix to specify stricter requirements on functions than standard c, the fact that the man page never makes any note of this being an extension (neither strtod(3) nor the posix specification strtod(3p)) is really notable to me.
whether or not posix's behavior is even compatible with standard c is... unclear. at least for math.h functions, setting errno regardless of the value of math_errhandling is permitted:
7.12.2p8:
\n\n\nIf a domain, pole, or range error occurs and the integer expression
\nmath_errhandling & MATH_ERRNOis zero, thenerrnoshall either be set to the value corresponding to the error or left unmodified.
but earlier on, when specifying errno.h, the standard says this:
7.5p3:
\n\n\n[...] The value of
\nerrnomay be set to nonzero by a library function call whether or not there is an error, provided the use oferrnois not documented in the description of the function in this document.
errno is documented in the description for these functions, and that description makes no mention of setting errno when math_errhandling & MATH_ERRNO is zero. so that suggests that posix's behavior is non-conformant.
but hang on! everything i've talked about so far is only for overflow and underflow. but if the string is malformed and can't be parsed as a number, then the standard doesn't specify any error at all:
\n7.25.2.6p11:
\n\n\nThe functions return the converted value, if any. If no conversion could be performed, positive or unsigned zero is returned.
\n
instead, you're supposed to use the endptr parameter, and check afterward if endptr == nptr (i.e. the end pointer is the same as the start pointer, so no data was parsed):
7.25.2.6p8:
\n\n\nIf the subject sequence is empty or does not have the expected form, no conversion is performed; the value of
\nnptris stored in the object pointed to byendptr, provided thatendptris not a null pointer.
the man page strtod(3) says something similar:
\n\nIf no conversion is performed, zero is returned and (unless
\nendptris null) the value ofnptris stored in the location referenced byendptr.
but check out what posix says:
\n\n\nUpon successful completion, these functions shall return the converted value. If no conversion could be performed, 0 shall be returned, and
\nerrnomay be set to[EINVAL].
the word "may" basically means that it's implementation-defined. but this is a big deal, because it's pretty common to check for errors by doing something like this:
\nerrno = 0;\ndouble x = strtod(s, nullptr);\nif (errno != 0) {\n\t// ...\n}\nstrtod(3) suggests doing exactly this:
\n\nSince 0 can be legitimately returned on both success and failure, the calling program should set
\nerrnoto 0 before the call, and then determine if an error occurred by checking whethererrnohas a nonzero value after the call.
but even for posix-compatible libcs, this isn't portable! different conforming libcs may behave differently if no conversion can be performed. in fact...
\nerrno = 0;\nstrtod("x", nullptr);\nprintf("%d\\n", errno);\non glibc, this prints 0, because glibc's strtod never sets errno to EINVAL. musl, on the other hand, does set errno to EINVAL, so this prints "22". this is completely undocumented on the linux man page.
it's also, from my reading of the standard, not conformant to standard c, because it's setting errno to a nonzero value in a function with other documented error conditions (and as far as standard c is concerned, invalid input isn't an error condition). musl could defend itself by saying that, because it doesn't set errno in its math.h functions, the errno condition in strtod's description no longer applies, therefore there's no documented use for errno (since the use of errno is dependent on the value of math_errhandling). but that's clearly a stretch.
either way, it's clear to me that the standard needs clearer wording here.
\njust for fun, i figured i'd conclude with a list of all the "correct" ways to check for errors in the string to float conversion functions, just to hammer the point home:
\nif you're targeting posix, set errno to 0 before the call, and afterward check copysign(result, 1.0) == HUGE_VAL && errno == ERANGE.
otherwise, set errno to 0 and call feclearexcept(FE_OVERFLOW) before the call, and, if copysign(result, 1.0) == HUGE_VAL, either check errno == ERANGE or fetestexcept(FE_OVERFLOW) after the call, depending on the value of math_errhandling.
if you're targeting just one implementation, and you know which error-reporting methods it supports beforehand, you can skip the math_errhandling check and only support one of the two methods.
if you're using feclearexcept/fetestexcept, make sure that the compiler knows you may be accessing the floating point environment: on gcc the relevant flag is -ftrapping-math, which is the default (unless you're using -ffast-math). there's also a standard pragma for this purpose: #pragma STDC FENV_ACCESS ON. this pragma isn't supported by gcc though.
if you're targeting posix, set errno to 0 before the call, and afterward check result == 0.0 && errno == ERANGE.
be sure to check specifically that errno is ERANGE, not just that it's nonzero. otherwise you'll end up with nonportable behavior.
otherwise, if you're just targeting one implementation, check if it documents its behavior on underflow in math.h functions. the behavior is implementation-defined, so technically it's required to document it. but in practice, even clang doesn't bother documenting its implementation-defined shit, so don't hold your breath.
but if it is documented, and it reports underflow errors, then, depending on the implementation's value of math_errhandling, either set errno to 0 before the call and check result == 0.0 && errno == ERANGE after the call, or call feclearexcept(FE_UNDERFLOW) before the call and check fetestexcept(FE_UNDERFLOW) after the call.
otherwise you're SOL.
\nif you reeally need to check for underflow, and you need to use the libc function for some reason, here's the only option i can think of: check if result == 0.0, and if so, check yourself if the input string contains any nonzero digits before the exponent. if so, underflow occurred. this is difficult to get right though; read the description of strtod et al from the standard and make sure you cover all edge-cases.
&endptr as a second argument to the function, and then check if endptr == nptr. errno can't be relied on.