Generic Containers in C: Safe Division Using Maybe

https://uecker.codeberg.page/2025-08-10.html

by uecker • 12 months ago

114 61 12 months ago

uecker.codeberg.page

nly2• 12 months ago

GCC generates essentially the same assembly for C++'s std::optional<int> with the exception that the result can't be returned in a register (a problem which will go away if the function is inlined)

https://gcc.godbolt.org/z/vfzK9Toz4

uecker19• 12 months ago

Yeah it a amazing a far C++ has come, soon it will be almost as good as C.

JonChesterfield• 12 months ago

In this instance C++ is far ahead of C, because what you want for maybe<> is typestate, and that's only available in C++ because it's wedded to member functions. See https://awesomekling.github.io/Catching-use-after-move-bugs-... or similar

pjmlp8• 12 months ago

Except that it is much more safer to use the type system than pre-processor glue based on text replacements, with more interesting error messages than templates.

wahern• 12 months ago

Is this because std::optional isn't trivially constructible?

pwdisswordfishz• 12 months ago

Destructible. Opportunistically making it trivially destructible does the trick.

pjmlp8• 12 months ago

Proving the point that better type system and abstractions don't necessarly produce bad Assembly, and if constexpr is used, there won't be anything on the final executable other than the actual value.

https://gcc.godbolt.org/z/31o75W5xx

https://gcc.godbolt.org/z/av6a43WeY

uecker19• 12 months ago

You do not need constexpr, just remove the "volatile" which I put into my example only to prevent the optimizer from specializing it: https://godbolt.org/z/fs8q3sdxK

But what matters is run-time behavior for any input. And sorry, C++'s complexity still has the effect that the code is terrible: https://godbolt.org/z/vWfjjf8rP

In C, the compiler can remove all error paths: https://godbolt.org/z/GGMcc6bxv

account42• 12 months ago

with the exception that the result can't be returned in a register (a problem which will go away if the function is inlined)

It's still a damned shame. Same for not being able to pass optional/unique_ptr/etc in a register.

We really need a trivially_relocatable attribute.

nextaccountic2• 12 months ago

Here, instead of handling the error condition, I create an lvalue that points nowhere in case of an error because it then corresponds to (({ (void)0; })), relying on the null sanitizer to transform it into a run-time trap for safety.

Isn't this undefined behavior?

lmm• 12 months ago

In standard C yes. But any decent C compiler will offer stronger guarantees than the minimum that the standard requires, and presumably the "null sanitizer" they're referring to is one of them.

pjmlp8• 12 months ago

As usual, the problem is not what they have been offering for the last decades in tooling, rather what developers actually make use of.

Unfortunely many keep needing education on such matters.

playforclaude• 12 months ago

Any decent C compiler will use loopholes in the standard to optimise your code :)

shakna• 12 months ago

Maybe, but it is defined for GCC:

You can store a null pointer in any lvalue whose data type is a pointer type. [0]

Though, I would expect a complaint from clang, and clang-tidy.

[0] https://www.gnu.org/software/c-intro-and-ref/manual/html_nod...

uecker19• 12 months ago

It is only undefined behavior if it is dereferenced, in which case the null sanitizer can be used to define it to trap, so safely terminate the program. But the example then also shows how you can make sure that this case is not even possible in the final program.

nextaccountic2• 11 months ago

It is actually dereferencing a null pointer (there is a * on the beginning of the definition of maybe_value). It is okay if you test for p.ok first, and UB otherwise. So it's like Option::unwrap_unchecked from Rust, not Option::unwrap that merely panics.

Relying on sanitizers to catch UB can only work in a best effort basis, because the compiler can perform optimizations that rely on the fact that the program doesn't have UB (and produces broken code if there is UB - beyond what a sanitizer could catch)

It would be much better to also provide another macro to abort the program if the maybe is nothing.

layer82• 12 months ago

The null sanitizer is used to define the behavior, which is one of the ways a C implementation is allowed to handle situations whose behavior the C standard leaves undefined.

rowanG0774• 12 months ago

At this point I always wonder why people who write stuff like this don't just move to a different language. You are introducing insane amounts of hidden complexity(see also the other posts on that blog). For something that just exists in other languages. Or maybe this is just a fun puzzle for the author, in which case it's totally fine.

throw-qqqqq5• 12 months ago

You don’t always get to choose your language. Especially in the embedded/firmware area of software development, C is the most widely available option, if not the only option besides ASM shrugs

rowanG0774• 12 months ago

Definitely. I still don't think you should swim against the stream. Just bite the bullet and write idiomatic C. The people who will have to debug your code in the future will thank you.

windward• 12 months ago

It is, but the bar of what's considered too 'clever' in embedded/firmware is usually lower than this. In fact, even the ternary conditional operator is too much.

fuhsnn• 12 months ago

The said library is a bit farther away from the C that is widely available. It relies on C23 features, GNU statement expression, GNU nested function, sanitizer runtimes, VLA types and a very niche pattern of sizeof executing its statement-expression argument; only platforms that provide latest GCC/Clang would be able to use this.

pjmlp8• 12 months ago

Unless you are talking about PIC and similar CPUs, there is hardly a modern 16 bit CPU that doesn't have a C++ compiler available as well, assuming that we still consider 16 bit modern for whatever reason.

Heck I learned to program in C++, back when DR-DOS 5 was the latest version, and all I had available was 640 KB to play around, leaving aside MEMMAX.

Nowadays the only reason many embedded developers keep using C is religous.

amiga386• 12 months ago

Quite. There's standard POSIX behaviour for this. Divide by zero and execution continues, safely, in your SIGFPE exception handler.

uecker19• 12 months ago

Because the different languages suck much more.

munchler2• 12 months ago

So this was inspired by Haskell, but you don’t actually think Haskell is a good language?

dazzawazza• 12 months ago

Other languages internalise that complexity. C leaves it bare, human scale and understandable.

The speed at which you can write great C code often far outstrips other languages which are applicable to the problem domain.

All languages are a compromise, there are no silver bullets.

uecker19• 11 months ago

BTW: I think what me annoys me about this comment is the claim that this would be "insane amounts of hidden complexity" . If you you look at the article, it four simple one-line macros:

#define maybe(T) struct maybe_##T { bool ok; T value; }

#define maybe_just(T, x) (maybe(T)){ .value = (x), .ok = true }

#define maybe_nothing(T) (maybe(T)){ .value = (T){ }, .ok = false }

#define maybe_value(T, x) (({ maybe(T) _p = &(x); _p->ok ? &_p->value : (void*)0; }))

Please compare this to your other languages.

rowanG0774• 11 months ago

Well yes I find these pretty insane. It's not ergonomic. It doesn't actually offer any safety. It has no integration with anything else. If I compare this to, for example, the rust Option, or Haskell's Maybe, it's not even funny how stark the difference is. And both of them are over the counter included.

Especially the the safety is something I can't step over. I don't feel it offers anything substantial over just having the struct without these macros.

yobbo• 12 months ago

It might be more useful with a signature like maybe_divide -> maybe(int) -> maybe(int) -> maybe(int) ... and then a set of operations over maybe, and functions/macros for and_then(), or_else(), etc. It would be interesting to see how ergonomic it could get.

munchler2• 12 months ago

I await the first “Monads in C” tutorial with mixed feelings.

uecker19• 12 months ago

Good idea. This is very easy, here is a preview. https://godbolt.org/z/dME1MMr19

BiraIgnacio• 12 months ago

I love seeing the creative ways people implement these types of, if I can say, high level abstractions in C. Thanks for sharing

uecker19• 11 months ago

Thank you!

teo_zero• 12 months ago

Clever, but it misses the very goal of option/maybe types: forcing the user to check the result. In this implementation nothing stops the user from omitting the "if (p.ok)" part and directly using "p.value".

It could work if "maybe(T)" is completely opaque to the user; both checking and accessing its payload must happen through helper macros; the checking macro ticks an invisible flag if ok; the accessing macro returns the payload only if the invisible flag is ticked, otherwise it triggers a runtime error/exception.

Not impossible. However, you would need to replace all "p.ok" with "maybe_check(p)", which is not unreasonable, and all "p.value" with "maybe_value(p)", which might be too much for the final user...

Generic Containers in C: Safe Division Using Maybe

Related Stories