{ "@context": "https://schema.org", "@id": "https://aggr.aymericbeaumet.com/items/hnrss-org/2026-10-13-your-c-is-not-standard-c/#webpage", "@type": [ "WebPage", "ArchiveComponent" ], "articleBody": "The committee has created an unreal language that no one can or will actually use.\\\n \\- [Dennis Ritchie](https://port70.net/~nsz/c/c89/dmr-on-noalias.html) (out of context)\n\nthis 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.\n\n## `asm`\n\nby 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.\n\nand 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.\n\n## `FLT_ROUNDS`\n\nthe standard specifies the `FLT_ROUNDS` macro in `float.h` as follows:\n\n5.3.5.3.3p23:\n\n> The rounding mode for floating-point addition for standard floating types is characterized by the implementation-defined value of `FLT_ROUNDS`. Evaluation of `FLT_ROUNDS` correctly reflects any execution-time change of rounding mode through the function `fesetround` in ``.\n\nnotably, 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:\n\n```\n/* Addition rounds to 0: zero, 1: nearest, 2: +inf, 3: -inf, -1: unknown. */\n/* ??? This is supposed to change with calls to fesetround in . */\n#undef FLT_ROUNDS\n#define FLT_ROUNDS 1\n```\n\nclang defines a builtin for this (`__builtin_flt_rounds()`), but gcc doesn't, for some reason.\n\n## standard pragmas\n\nat 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:\n\nthe c standard specifies five standard pragmas to control the behavior of floating point arithmetic:\n\n```\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\n```\n\nhowever, over 27 years after c99 was standardized, [gcc still doesn't support any of the standard pragmas](https://gcc.gnu.org/projects/c-status.html). they're just no-ops in gcc.\n\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.\n\nclang mostly supports the c99 pragmas, but still doesn't support the c23 pragmas.\n\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\n\n## qualifiers in function return types\n\nthe standard requires that qualifiers in function return types are discarded:\n\n> If, in the declaration \"`T D1`\", `D1` has the form\n>\n> ```\n> D ( parameter-type-listopt ) attribute-specifier-sequenceopt\n> ```\n>\n> and the type specified for *ident* in the declaration \"`T D`\" is \"*derived-declarator-type-list `T`*\", then the type specified for *ident* is \"*derived-declarator-type-list* function returning the unqualified, non-atomic version of `T`\". The optional attribute specifier appertains to the function type.\n\nbut clang treats them as significant:\n\n```\n$ cat t.c\nint f();\nconst int f();\n```\n\n```\n$ clang t.c\nt.c:2:11: error: conflicting types for 'f'\n 2 | const int f();\n | ^\nt.c:1:5: note: previous declaration is here\n 1 | int f();\n | ^\n1 error generated.\n```\n\nthe two declarations should be identical, but clang thinks they're incompatible.\n\n## outdated `va_start` definition on musl\n\nfor 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.\n\nthis is a problem because musl's header is strictly worse than the builtin header. here's how musl defines `va_start`:\n\n```\n#define va_start(v,l) __builtin_va_start(v,l)\n```\n\nthis definition is incorrect, because c23 allows the second argument to be omitted. it should be defined like this:\n\n```\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\n```\n\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.\n\n## see also\n\n- [notes on how glibc and musl handle math errors](https://sebsite.pw/w/20261004-math_errhandling.html) (`math_errhandling`)\n- [oh, apparently it's not possible to portably check for string-to-float conversion errors in standard c](https://sebsite.pw/w/20261009-strtod.html): a case where posix arguably specifies a family of functions incompatibly from standard c\n- [neither gcc nor clang are compliant with standard c++](https://sebsite.pw/w/20260708-badstdcxx.html): gcc and clang don't store language linkage information with function types in c++, contrary to what the standard requires\n- [yet another place where a linux man page is inaccurate](https://sebsite.pw/w/20261014-initstate.html) (containing a deleted section from this post!)\n", "authors": [ "dverlaeckt80" ], "captured_at": "2026-10-15T14:23:03.950687001+00:00", "category": "news", "content_html": "

The committee has created an unreal language that no one can or will actually use.
\n- Dennis Ritchie (out of context)

\n

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.

\n

asm

\n

by 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.

\n

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.

\n

FLT_ROUNDS

\n

the standard specifies the FLT_ROUNDS macro in float.h as follows:

\n

5.3.5.3.3p23:

\n
\n

The rounding mode for floating-point addition for standard floating types is characterized by the implementation-defined value of FLT_ROUNDS. Evaluation of FLT_ROUNDS correctly reflects any execution-time change of rounding mode through the function fesetround in <fenv.h>.

\n
\n

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:

\n
/* 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\n
\n

clang defines a builtin for this (__builtin_flt_rounds()), but gcc doesn't, for some reason.

\n

standard pragmas

\n

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:

\n

the 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\n
\n

however, over 27 years after c99 was standardized, gcc still doesn't support any of the standard pragmas. they're just no-ops in gcc.

\n

some (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.

\n

clang mostly supports the c99 pragmas, but still doesn't support the c23 pragmas.

\n

there'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

\n

qualifiers in function return types

\n

the standard requires that qualifiers in function return types are discarded:

\n
\n

If, in the declaration "T D1", D1 has the form

\n
D ( parameter-type-listopt ) attribute-specifier-sequenceopt\n
\n

and the type specified for ident in the declaration "T D" is "derived-declarator-type-list T", then the type specified for ident is "derived-declarator-type-list function returning the unqualified, non-atomic version of T". The optional attribute specifier appertains to the function type.

\n
\n

but clang treats them as significant:

\n
$ cat t.c\nint f();\nconst int f();\n
\n
$ clang t.c\nt.c:2:11: error: conflicting types for 'f'\n    2 | const int f();\n      |           ^\nt.c:1:5: note: previous declaration is here\n    1 | int f();\n      |     ^\n1 error generated.\n
\n

the two declarations should be identical, but clang thinks they're incompatible.

\n

outdated va_start definition on musl

\n

for 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.

\n

this is a problem because musl's header is strictly worse than the builtin header. here's how musl defines va_start:

\n
#define va_start(v,l)   __builtin_va_start(v,l)\n
\n

this 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\n
\n

the 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.

\n

see also

\n\n", "content_markdown": "The committee has created an unreal language that no one can or will actually use.\\\n \\- [Dennis Ritchie](https://port70.net/~nsz/c/c89/dmr-on-noalias.html) (out of context)\n\nthis 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.\n\n## `asm`\n\nby 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.\n\nand 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.\n\n## `FLT_ROUNDS`\n\nthe standard specifies the `FLT_ROUNDS` macro in `float.h` as follows:\n\n5.3.5.3.3p23:\n\n> The rounding mode for floating-point addition for standard floating types is characterized by the implementation-defined value of `FLT_ROUNDS`. Evaluation of `FLT_ROUNDS` correctly reflects any execution-time change of rounding mode through the function `fesetround` in ``.\n\nnotably, 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:\n\n```\n/* Addition rounds to 0: zero, 1: nearest, 2: +inf, 3: -inf, -1: unknown. */\n/* ??? This is supposed to change with calls to fesetround in . */\n#undef FLT_ROUNDS\n#define FLT_ROUNDS 1\n```\n\nclang defines a builtin for this (`__builtin_flt_rounds()`), but gcc doesn't, for some reason.\n\n## standard pragmas\n\nat 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:\n\nthe c standard specifies five standard pragmas to control the behavior of floating point arithmetic:\n\n```\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\n```\n\nhowever, over 27 years after c99 was standardized, [gcc still doesn't support any of the standard pragmas](https://gcc.gnu.org/projects/c-status.html). they're just no-ops in gcc.\n\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.\n\nclang mostly supports the c99 pragmas, but still doesn't support the c23 pragmas.\n\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\n\n## qualifiers in function return types\n\nthe standard requires that qualifiers in function return types are discarded:\n\n> If, in the declaration \"`T D1`\", `D1` has the form\n>\n> ```\n> D ( parameter-type-listopt ) attribute-specifier-sequenceopt\n> ```\n>\n> and the type specified for *ident* in the declaration \"`T D`\" is \"*derived-declarator-type-list `T`*\", then the type specified for *ident* is \"*derived-declarator-type-list* function returning the unqualified, non-atomic version of `T`\". The optional attribute specifier appertains to the function type.\n\nbut clang treats them as significant:\n\n```\n$ cat t.c\nint f();\nconst int f();\n```\n\n```\n$ clang t.c\nt.c:2:11: error: conflicting types for 'f'\n 2 | const int f();\n | ^\nt.c:1:5: note: previous declaration is here\n 1 | int f();\n | ^\n1 error generated.\n```\n\nthe two declarations should be identical, but clang thinks they're incompatible.\n\n## outdated `va_start` definition on musl\n\nfor 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.\n\nthis is a problem because musl's header is strictly worse than the builtin header. here's how musl defines `va_start`:\n\n```\n#define va_start(v,l) __builtin_va_start(v,l)\n```\n\nthis definition is incorrect, because c23 allows the second argument to be omitted. it should be defined like this:\n\n```\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\n```\n\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.\n\n## see also\n\n- [notes on how glibc and musl handle math errors](https://sebsite.pw/w/20261004-math_errhandling.html) (`math_errhandling`)\n- [oh, apparently it's not possible to portably check for string-to-float conversion errors in standard c](https://sebsite.pw/w/20261009-strtod.html): a case where posix arguably specifies a family of functions incompatibly from standard c\n- [neither gcc nor clang are compliant with standard c++](https://sebsite.pw/w/20260708-badstdcxx.html): gcc and clang don't store language linkage information with function types in c++, contrary to what the standard requires\n- [yet another place where a linux man page is inaccurate](https://sebsite.pw/w/20261014-initstate.html) (containing a deleted section from this post!)\n", "dateCreated": "2026-10-15T14:23:03.950687001+00:00", "date_created": "2026-10-13T13:36:21+00:00", "date_modified": "2026-10-13T13:36:21+00:00", "date_published": "2026-10-13T13:36:21+00:00", "description": "The committee has created an unreal language that no one can or will actually use. - 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…", "external_url": "https://sebsite.pw/w/20261012-notstdc.html", "git": { "commit": "ebb0941c5c06a2ab2377342d607535262a3e969e", "path": "items/hnrss-org/2026/10/2026-10-13-your-c-is-not-standard-c.md", "permalink": "https://github.com/aymericbeaumet/aggr-instance/blob/ebb0941c5c06a2ab2377342d607535262a3e969e/items/hnrss-org/2026/10/2026-10-13-your-c-is-not-standard-c.md" }, "id": "urn:aggr:item:a1bbc7e07f353e77b8f5028c1d935f6f76ebef79", "isBasedOn": { "@id": "https://sebsite.pw/w/20261012-notstdc.html" }, "mainEntity": { "@id": "https://sebsite.pw/w/20261012-notstdc.html", "@type": "CreativeWork", "archivedAt": { "@id": "https://aggr.aymericbeaumet.com/items/hnrss-org/2026-10-13-your-c-is-not-standard-c/#webpage" }, "author": [ { "@type": "Person", "name": "dverlaeckt80" } ], "dateModified": "2026-10-13T13:36:21+00:00", "datePublished": "2026-10-13T13:36:21+00:00", "headline": "Your C is not standard C", "timeRequired": "PT4M", "url": "https://sebsite.pw/w/20261012-notstdc.html", "wordCount": 826 }, "name": "Archived snapshot: Your C is not standard C", "preview": null, "reading_minutes": 4, "replicated_at": null, "source": "hnrss-org", "source_name": "Hacker News: Front Page", "summary": null, "tags": [], "temporalCoverage": "2026-10-15T14:23:03.950687001+00:00", "title": "Your C is not standard C", "url": "https://aggr.aymericbeaumet.com/items/hnrss-org/2026-10-13-your-c-is-not-standard-c/", "word_count": 826 }