{ "@context": "https://schema.org", "@id": "https://aggr.aymericbeaumet.com/items/lobste-rs/2026-10-15-my-c23-conventions/#webpage", "@type": [ "WebPage", "ArchiveComponent" ], "articleBody": "This is one of a three-part mini series about how I’m using modern C as of late 2026.\n\nBefore C23, I was [taken in](https://www.youtube.com/watch?v=443UNeGrFoM) by *How I Program C* for years and years, and would even feel guilty for choosing C99 instead of `-ansi -pedantic`. But holy crap man I’m done being a doomsday prepper! These days I maintain a large-enough project with enough users where I could stand less foot-shooting. (I’ve also got bills to pay.)\n\nSo here’s three modern C conventions which started to rise naturally from adding `-std=c23` to my zig build:\n\n## 1\\. Unused? Maybe. (Yes)\n\nOur first convention is centered around `[[nodiscard]]`. If I draw an app window or panel I require the caller to interrogate the rect of the thing that was just rendered:\n\n```c\n[[nodiscard]] rect_t draw_screen(/* ... */) {\n rect_t screen_r = { };\n // Draw stuff\n // ...\n return screen_r;\n}\n```\n\nIt’s a genuine business logic bug if the caller doesn’t capture the rectangle for later processing. Therefore `[[nodiscard]]` has been such a godsend for fixing bugs… Except there’s a choice few instances where I will draw something with *no real use* for the resulting rect. I’d rather ignore the return value:\n\n```c\nenum screen_opt popup_options = /* ... */ ;\ndraw_screen(popup_options, /* ... */); // ERROR: damn you [[nodiscard]]\n```\n\nClang will error out here. I could maybe capture the var and never use it but…\n\n```c\nrect_t rect = draw_screen(/* ... */); // ERROR: unused variable (I have `-Werror` enabled)\n```\n\nPre-C23 one might solve this through an `UNUSED()` macro:\n\n```c\n#ifndef UNUSED\n#define UNUSED(x) (void)(x)\n#endif\n\nrect_t rect = draw_screen(/* ... */);\nUNUSED(rect); // Silences the compiler, but now I'm sad.\n```\n\nBut now with C23 we can delete the macro in favor of the native `[[maybe_unused]]`:\n\n```c\n[[maybe_unused]] rect_t rect = draw_screen(...); // OK\n```\n\nPhew I feel better. I’ve also noticed this is happening all over the place: lots of different routines returning different types that are marked with `[[nodiscard]]`. So for all the unused cases why not just go for:\n\n```c\n[[maybe_unused]] auto _ = foo(); // A new pattern emerges\n```\n\nBonus: For any macro fans out there a fellow indie dev (Zardium) offered an additional improvement. From our chat server:\n\n> Zardium: #define \\_ \\[\\[maybe\\_unused\\]\\] auto CONCAT\\_MACRO(zz,**COUNTER**)\n\n> Abner: ahh, unique varname. nice one\n\n> Zardium: you could take the auto out if you don’t want it to look so weird. then it acts exactly like the \\_ in other languages, where it can be redefined\n\n> Abner: Yep totally. Although here I was celebrating my removal of a macro… XD\n\n## 2\\. More Perfect Unions\n\nI’ve been cheated and lied to: designated initializers DO NOT clear my struct to zero and I can’t even trust `{0}` anymore. (Talk about a betrayal.) The problem is I’ll often have data types like this contrived timestamp:\n\n```c\ntypedef struct {\n Type type;\n char buf[MAX];\n union {\n time_t time;\n float dt;\n date_t date;\n };\n} stamp_t;\n```\n\nAnd if I partially initialize one:\n\n```c\nstamp_t stamp = { .type = STAMP_TYPE_BLA_BLA };\n```\n\nWhile it does mean we successfully zeroed out `buf` (thanks to [empty initialization](https://en.cppreference.com/c/language/initialization#Empty_initialization)), those union members are just a different beast. It also doesn’t matter if we go with `stamp_t stamp = {0}` instead. My dear reader: I’ve made the costly mistake of assuming `date` would clear to zero!\n\nAs I Spongebob-panicked in public, Lobsters member [accelbread](https://lobste.rs/~accelbread) offered a sage revelation:\n\n> accelbread: It used to be that GCC would fully zero the union anyways, and clang would only zero the time\\_t, though around a year ago they swapped behaviors iirc. Either way, standard only requires the time\\_t be zeroed and not whole union. GCC has a flag to always zero whole union. Also C23 initialization always inits whole union\n\nWait WHAT? clang and gcc SWAPPED what now? I won’t investigate further. Everything about this is *dangerous af* unless we hug C23 tightly and never let go:\n\n```c\nstamp_t stamp = { }; // Fully clears to zero (C23)\nstamp.type = STAMP_TYPE_BLA_BLA;\n```\n\nAccelbread went on to say two more things:\n\n1. *“Note the C23 zero init whole thing is nothing in the brackets, not 0 in brackets; { 0 } does same thing as before C23”*\n2. *“Also if you control union layout, putting largest member first is safest”*\n\nYessir.\n\n## 3\\. Enums In C Were Magic (And I Don’t Like It)\n\nIf I want to customize some dialog box I’ll use bit flags:\n\n```c\nenum {\n OPT_AUTOSCROLL = (1 << 0),\n OPT_NOCURSOR = (1 << 1),\n OPT_CENTERED = (1 << 2),\n OPT_NOCLOSE = (1 << 3),\n // ...\n};\n\n[[nodiscard]] bool draw_warning(const char* msg, int opt);\n```\n\nEven if we disagree with this approach lots of relevant libraries or projects do it:\n\n```c\n_ = draw_warning(\"you done messed up A-A-RON\", OPT_CENTERED | OPT_NOCLOSE);\n```\n\nOf course, erroneous bit shifting will land anyone into trouble and yield comical numbers. Thankfully C enums are a plain `int` underneath so the compiler will warn us if we defined a bad constant inside the enum that won’t fit.\n\n:)\n\nI’m kidding. Sigh. Well, I’m growing fearful of sage revelations but this one comes from [Modern C](https://gustedt.gitlabpages.inria.fr/modern-c/) by Jens Gustedt:\n\n> Jens: If enumeration constants do not fit into signed int, if possible, the enumeration type is adjusted such that it can store all enumeration constants.\n\nNoooooo!\n\n> Jens: The property that an an enumeration type is adjusted such that it fits all its constants could have surprising effects\n\n*sobs*\n\n> Jens: So, it is preferable to specify the underlying integer type explicitly\n\nTHERE IS HOPE?\n\n```c\nenum options : int {\n OPT_AUTOSCROLL = (1 << 0),\n OPT_NOCURSOR = (1 << 1),\n OPT_CENTERED = (1 << 2),\n OPT_NOCLOSE = (1 << 3),\n // ...\n};\n```\n\nIt compiles! We shoot. We score. We stick with C23.\n\n## Epilogue\n\nIn part two of our mini series I’ll discuss three more conventions that I’ve fleshed out thanks to modern C: starting with safer macro usage (forgive me Zig folks.)\n\n*P.S. If you want to shape this discussion [maybe join](https://handmadecities.com/chat) the Handmade Cities server!*\n\n-Abner\n", "authors": [ "abner.page by abnercoimbre" ], "captured_at": "2026-10-16T22:01:23.127136231+00:00", "category": "news", "content_html": "

This is one of a three-part mini series about how I’m using modern C as of late 2026.

\n

Before C23, I was taken in by How I Program C for years and years, and would even feel guilty for choosing C99 instead of -ansi -pedantic. But holy crap man I’m done being a doomsday prepper! These days I maintain a large-enough project with enough users where I could stand less foot-shooting. (I’ve also got bills to pay.)

\n

So here’s three modern C conventions which started to rise naturally from adding -std=c23 to my zig build:

\n

1. Unused? Maybe. (Yes)

\n

Our first convention is centered around [[nodiscard]]. If I draw an app window or panel I require the caller to interrogate the rect of the thing that was just rendered:

\n
[[nodiscard]] rect_t draw_screen(/* ... */) {\n    rect_t screen_r = { };\n    // Draw stuff\n    // ...\n    return screen_r;\n}\n
\n

It’s a genuine business logic bug if the caller doesn’t capture the rectangle for later processing. Therefore [[nodiscard]] has been such a godsend for fixing bugs… Except there’s a choice few instances where I will draw something with no real use for the resulting rect. I’d rather ignore the return value:

\n
enum screen_opt popup_options = /* ... */ ;\ndraw_screen(popup_options, /* ... */); // ERROR: damn you [[nodiscard]]\n
\n

Clang will error out here. I could maybe capture the var and never use it but…

\n
rect_t rect = draw_screen(/* ... */); // ERROR: unused variable (I have `-Werror` enabled)\n
\n

Pre-C23 one might solve this through an UNUSED() macro:

\n
#ifndef UNUSED\n#define UNUSED(x) (void)(x)\n#endif\n\nrect_t rect = draw_screen(/* ... */);\nUNUSED(rect); // Silences the compiler, but now I'm sad.\n
\n

But now with C23 we can delete the macro in favor of the native [[maybe_unused]]:

\n
[[maybe_unused]] rect_t rect = draw_screen(...); // OK\n
\n

Phew I feel better. I’ve also noticed this is happening all over the place: lots of different routines returning different types that are marked with [[nodiscard]]. So for all the unused cases why not just go for:

\n
[[maybe_unused]] auto _ = foo(); // A new pattern emerges\n
\n

Bonus: For any macro fans out there a fellow indie dev (Zardium) offered an additional improvement. From our chat server:

\n
\n

Zardium: #define _ [[maybe_unused]] auto CONCAT_MACRO(zz,COUNTER)

\n
\n
\n

Abner: ahh, unique varname. nice one

\n
\n
\n

Zardium: you could take the auto out if you don’t want it to look so weird. then it acts exactly like the _ in other languages, where it can be redefined

\n
\n
\n

Abner: Yep totally. Although here I was celebrating my removal of a macro… XD

\n
\n

2. More Perfect Unions

\n

I’ve been cheated and lied to: designated initializers DO NOT clear my struct to zero and I can’t even trust {0} anymore. (Talk about a betrayal.) The problem is I’ll often have data types like this contrived timestamp:

\n
typedef struct {\n    Type type;\n    char buf[MAX];\n    union {\n        time_t time;\n        float dt;\n        date_t date;\n    };\n} stamp_t;\n
\n

And if I partially initialize one:

\n
stamp_t stamp = { .type = STAMP_TYPE_BLA_BLA };\n
\n

While it does mean we successfully zeroed out buf (thanks to empty initialization), those union members are just a different beast. It also doesn’t matter if we go with stamp_t stamp = {0} instead. My dear reader: I’ve made the costly mistake of assuming date would clear to zero!

\n

As I Spongebob-panicked in public, Lobsters member accelbread offered a sage revelation:

\n
\n

accelbread: It used to be that GCC would fully zero the union anyways, and clang would only zero the time_t, though around a year ago they swapped behaviors iirc. Either way, standard only requires the time_t be zeroed and not whole union. GCC has a flag to always zero whole union. Also C23 initialization always inits whole union

\n
\n

Wait WHAT? clang and gcc SWAPPED what now? I won’t investigate further. Everything about this is dangerous af unless we hug C23 tightly and never let go:

\n
stamp_t stamp = { }; // Fully clears to zero (C23)\nstamp.type = STAMP_TYPE_BLA_BLA;\n
\n

Accelbread went on to say two more things:

\n
    \n
  1. “Note the C23 zero init whole thing is nothing in the brackets, not 0 in brackets; { 0 } does same thing as before C23”
    2. \n
  2. “Also if you control union layout, putting largest member first is safest”
    3. \n
\n

Yessir.

\n

3. Enums In C Were Magic (And I Don’t Like It)

\n

If I want to customize some dialog box I’ll use bit flags:

\n
enum {\n    OPT_AUTOSCROLL = (1 << 0),\n    OPT_NOCURSOR   = (1 << 1),\n    OPT_CENTERED   = (1 << 2),\n    OPT_NOCLOSE    = (1 << 3),\n    // ...\n};\n\n[[nodiscard]] bool draw_warning(const char* msg, int opt);\n
\n

Even if we disagree with this approach lots of relevant libraries or projects do it:

\n
_ = draw_warning("you done messed up A-A-RON", OPT_CENTERED | OPT_NOCLOSE);\n
\n

Of course, erroneous bit shifting will land anyone into trouble and yield comical numbers. Thankfully C enums are a plain int underneath so the compiler will warn us if we defined a bad constant inside the enum that won’t fit.

\n

:)

\n

I’m kidding. Sigh. Well, I’m growing fearful of sage revelations but this one comes from Modern C by Jens Gustedt:

\n
\n

Jens: If enumeration constants do not fit into signed int, if possible, the enumeration type is adjusted such that it can store all enumeration constants.

\n
\n

Noooooo!

\n
\n

Jens: The property that an an enumeration type is adjusted such that it fits all its constants could have surprising effects

\n
\n

sobs

\n
\n

Jens: So, it is preferable to specify the underlying integer type explicitly

\n
\n

THERE IS HOPE?

\n
enum options : int {\n    OPT_AUTOSCROLL = (1 << 0),\n    OPT_NOCURSOR   = (1 << 1),\n    OPT_CENTERED   = (1 << 2),\n    OPT_NOCLOSE    = (1 << 3),\n    // ...\n};\n
\n

It compiles! We shoot. We score. We stick with C23.

\n

Epilogue

\n

In part two of our mini series I’ll discuss three more conventions that I’ve fleshed out thanks to modern C: starting with safer macro usage (forgive me Zig folks.)

\n

P.S. If you want to shape this discussion maybe join the Handmade Cities server!

\n

-Abner

\n", "content_markdown": "This is one of a three-part mini series about how I’m using modern C as of late 2026.\n\nBefore C23, I was [taken in](https://www.youtube.com/watch?v=443UNeGrFoM) by *How I Program C* for years and years, and would even feel guilty for choosing C99 instead of `-ansi -pedantic`. But holy crap man I’m done being a doomsday prepper! These days I maintain a large-enough project with enough users where I could stand less foot-shooting. (I’ve also got bills to pay.)\n\nSo here’s three modern C conventions which started to rise naturally from adding `-std=c23` to my zig build:\n\n## 1\\. Unused? Maybe. (Yes)\n\nOur first convention is centered around `[[nodiscard]]`. If I draw an app window or panel I require the caller to interrogate the rect of the thing that was just rendered:\n\n```c\n[[nodiscard]] rect_t draw_screen(/* ... */) {\n rect_t screen_r = { };\n // Draw stuff\n // ...\n return screen_r;\n}\n```\n\nIt’s a genuine business logic bug if the caller doesn’t capture the rectangle for later processing. Therefore `[[nodiscard]]` has been such a godsend for fixing bugs… Except there’s a choice few instances where I will draw something with *no real use* for the resulting rect. I’d rather ignore the return value:\n\n```c\nenum screen_opt popup_options = /* ... */ ;\ndraw_screen(popup_options, /* ... */); // ERROR: damn you [[nodiscard]]\n```\n\nClang will error out here. I could maybe capture the var and never use it but…\n\n```c\nrect_t rect = draw_screen(/* ... */); // ERROR: unused variable (I have `-Werror` enabled)\n```\n\nPre-C23 one might solve this through an `UNUSED()` macro:\n\n```c\n#ifndef UNUSED\n#define UNUSED(x) (void)(x)\n#endif\n\nrect_t rect = draw_screen(/* ... */);\nUNUSED(rect); // Silences the compiler, but now I'm sad.\n```\n\nBut now with C23 we can delete the macro in favor of the native `[[maybe_unused]]`:\n\n```c\n[[maybe_unused]] rect_t rect = draw_screen(...); // OK\n```\n\nPhew I feel better. I’ve also noticed this is happening all over the place: lots of different routines returning different types that are marked with `[[nodiscard]]`. So for all the unused cases why not just go for:\n\n```c\n[[maybe_unused]] auto _ = foo(); // A new pattern emerges\n```\n\nBonus: For any macro fans out there a fellow indie dev (Zardium) offered an additional improvement. From our chat server:\n\n> Zardium: #define \\_ \\[\\[maybe\\_unused\\]\\] auto CONCAT\\_MACRO(zz,**COUNTER**)\n\n> Abner: ahh, unique varname. nice one\n\n> Zardium: you could take the auto out if you don’t want it to look so weird. then it acts exactly like the \\_ in other languages, where it can be redefined\n\n> Abner: Yep totally. Although here I was celebrating my removal of a macro… XD\n\n## 2\\. More Perfect Unions\n\nI’ve been cheated and lied to: designated initializers DO NOT clear my struct to zero and I can’t even trust `{0}` anymore. (Talk about a betrayal.) The problem is I’ll often have data types like this contrived timestamp:\n\n```c\ntypedef struct {\n Type type;\n char buf[MAX];\n union {\n time_t time;\n float dt;\n date_t date;\n };\n} stamp_t;\n```\n\nAnd if I partially initialize one:\n\n```c\nstamp_t stamp = { .type = STAMP_TYPE_BLA_BLA };\n```\n\nWhile it does mean we successfully zeroed out `buf` (thanks to [empty initialization](https://en.cppreference.com/c/language/initialization#Empty_initialization)), those union members are just a different beast. It also doesn’t matter if we go with `stamp_t stamp = {0}` instead. My dear reader: I’ve made the costly mistake of assuming `date` would clear to zero!\n\nAs I Spongebob-panicked in public, Lobsters member [accelbread](https://lobste.rs/~accelbread) offered a sage revelation:\n\n> accelbread: It used to be that GCC would fully zero the union anyways, and clang would only zero the time\\_t, though around a year ago they swapped behaviors iirc. Either way, standard only requires the time\\_t be zeroed and not whole union. GCC has a flag to always zero whole union. Also C23 initialization always inits whole union\n\nWait WHAT? clang and gcc SWAPPED what now? I won’t investigate further. Everything about this is *dangerous af* unless we hug C23 tightly and never let go:\n\n```c\nstamp_t stamp = { }; // Fully clears to zero (C23)\nstamp.type = STAMP_TYPE_BLA_BLA;\n```\n\nAccelbread went on to say two more things:\n\n1. *“Note the C23 zero init whole thing is nothing in the brackets, not 0 in brackets; { 0 } does same thing as before C23”*\n2. *“Also if you control union layout, putting largest member first is safest”*\n\nYessir.\n\n## 3\\. Enums In C Were Magic (And I Don’t Like It)\n\nIf I want to customize some dialog box I’ll use bit flags:\n\n```c\nenum {\n OPT_AUTOSCROLL = (1 << 0),\n OPT_NOCURSOR = (1 << 1),\n OPT_CENTERED = (1 << 2),\n OPT_NOCLOSE = (1 << 3),\n // ...\n};\n\n[[nodiscard]] bool draw_warning(const char* msg, int opt);\n```\n\nEven if we disagree with this approach lots of relevant libraries or projects do it:\n\n```c\n_ = draw_warning(\"you done messed up A-A-RON\", OPT_CENTERED | OPT_NOCLOSE);\n```\n\nOf course, erroneous bit shifting will land anyone into trouble and yield comical numbers. Thankfully C enums are a plain `int` underneath so the compiler will warn us if we defined a bad constant inside the enum that won’t fit.\n\n:)\n\nI’m kidding. Sigh. Well, I’m growing fearful of sage revelations but this one comes from [Modern C](https://gustedt.gitlabpages.inria.fr/modern-c/) by Jens Gustedt:\n\n> Jens: If enumeration constants do not fit into signed int, if possible, the enumeration type is adjusted such that it can store all enumeration constants.\n\nNoooooo!\n\n> Jens: The property that an an enumeration type is adjusted such that it fits all its constants could have surprising effects\n\n*sobs*\n\n> Jens: So, it is preferable to specify the underlying integer type explicitly\n\nTHERE IS HOPE?\n\n```c\nenum options : int {\n OPT_AUTOSCROLL = (1 << 0),\n OPT_NOCURSOR = (1 << 1),\n OPT_CENTERED = (1 << 2),\n OPT_NOCLOSE = (1 << 3),\n // ...\n};\n```\n\nIt compiles! We shoot. We score. We stick with C23.\n\n## Epilogue\n\nIn part two of our mini series I’ll discuss three more conventions that I’ve fleshed out thanks to modern C: starting with safer macro usage (forgive me Zig folks.)\n\n*P.S. If you want to shape this discussion [maybe join](https://handmadecities.com/chat) the Handmade Cities server!*\n\n-Abner\n", "dateCreated": "2026-10-16T22:01:23.127136231+00:00", "date_created": "2026-10-15T15:32:15+00:00", "date_modified": "2026-10-15T15:32:15+00:00", "date_published": "2026-10-15T15:32:15+00:00", "description": "Comments", "external_url": "https://abner.page/post/c23-conventions-1/", "git": { "commit": "ebb0941c5c06a2ab2377342d607535262a3e969e", "path": "items/lobste-rs/2026/10/2026-10-15-my-c23-conventions.md", "permalink": "https://github.com/aymericbeaumet/aggr-instance/blob/ebb0941c5c06a2ab2377342d607535262a3e969e/items/lobste-rs/2026/10/2026-10-15-my-c23-conventions.md" }, "id": "urn:aggr:item:30606cb70eb4e7f84f6bdd70afea228b1000544d", "isBasedOn": { "@id": "https://abner.page/post/c23-conventions-1/" }, "mainEntity": { "@id": "https://abner.page/post/c23-conventions-1/", "@type": "CreativeWork", "archivedAt": { "@id": "https://aggr.aymericbeaumet.com/items/lobste-rs/2026-10-15-my-c23-conventions/#webpage" }, "author": [ { "@type": "Person", "name": "abner.page by abnercoimbre" } ], "dateModified": "2026-10-15T15:32:15+00:00", "datePublished": "2026-10-15T15:32:15+00:00", "headline": "My C23 Conventions", "timeRequired": "PT5M", "url": "https://abner.page/post/c23-conventions-1/", "wordCount": 927 }, "name": "Archived snapshot: My C23 Conventions", "preview": null, "reading_minutes": 5, "replicated_at": null, "source": "lobste-rs", "source_name": "Lobsters: Top Stories of the Past Week", "summary": "Comments", "tags": [ "c" ], "temporalCoverage": "2026-10-16T22:01:23.127136231+00:00", "title": "My C23 Conventions", "url": "https://aggr.aymericbeaumet.com/items/lobste-rs/2026-10-15-my-c23-conventions/", "word_count": 927 }