wicked witch of the unix

♫♪ never fade away ♪♫

openrc maintainer, works on wine

<3 akkoma flavored lizzy (fleckenstein@lizzy.rs) (npub13qr…egvc)
<3 rose (npub1xz9…wuhw)

pronouns: she/her

Last Notes

2026-10-11 09:42:53 UTC

- reply

as in like:
```
type foo;
foo.nya = ...;
foo.mew = ...;
defer {
free(foo.nya);
free(foo.mew);
}
```
or? i'm not sure what "more local cleanup" would mean
i'm going by the most common api pattern i see out there, that is, if `make_foo()` returns success, it means the struct was fully allocated, and free_foo() deallocates all it needs
if make_foo() can fail, then i'd be something more like:
```c
type foo;
if ((err = make_foo(&foo)))
return err;
defer free_foo(foo);
...;
type nya;
if ((err = make_nya(&nya, &foo)))
return err;
defer free_nya(nya);
```
(defer could also help inside those constructors, by a pattern like
```c
enum myerr err = OK;
struct foo *foo = ...;
defer if (err != OK) free_foo(foo);
...;
if (some_cond() == FAIL)
return (err = COND_FAILED);
```
ofc this also depends on your data structure for foo
as a side note, for "handle every kind of failure":
it's a lot better if you employ some sort of zii (zero is initialization), since then you can calloc() foo, (or for a stack structure, `foo = {};`) to zero it out; have free_foo cleanup when non-0 where possible, it's one of the reasons `free(NULL);` is a noop
i don't have to care much *where* something failed and the destructor got called, since everything that wasn't allocated would be a zero or some other value that can either be checked or noops (the only exception is usually fds where you have to assign -1, for this you can use a `foo = FOO_INIT;` macro, or just assign by hand, `foo = { .myfd = -1 }`, it's annoying but works)

2026-10-11 09:23:15 UTC

- reply

i don't see how that constrains anything? deferred blocks would be called on basically the same order as c++ destructors, plus you can defer whole blocks if you need more at cleanup time
and i take
```c
type *foo = make_foo();
defer free_foo(foo);
// ...;
if ((err = some_call()))
return err;
type *nya = make_nya(&foo);
defer free_nya(nya);
if ((err = some_other_call()))
return err;
//...;
```
over
```c
type *foo = make_foo();
// ...;
if ((err = some_call()))
goto cleanup_foo;
// ...;
type *nya = make_nya(&foo);
if ((err = some_other_call()))
goto cleanup_nya;
// ...;
cleanup_nya:
free_nya(nya);
cleanup_foo:
free_foo(foo);
return err;
```
for the defer example, i see foo, i see deferring it's cleanup, i don't think about foo's resources on exit anymore
on the goto example, i constantly have to think about it, if i change some calls around i gotta double check which labels it's jumping to, it's a lot easier to make a mistake refactoring and get a double-free or leak
and to me, defer is not any less explicit, for the goto example if i'm looking at the cleanup at the end i have to be aware of every single point in the function that jumps to it, i have to personally keep track of allocation order to make sure cleanup order is correct (nya takes a foo, so foo *has* to be cleaned up later)
defer just handles all that by design, all i have to do is keep the defer close to the allocation and now i don't have to worry much about ordering on the 99% of common cases; it's still explicit, it's still there in the function telling me the flow, it's not like destructors living in another file completely and being called implicitly
(and sure defer isn't idea on every case, it's made to avoid common mistakes, just like we have `for (init; cond; end) body;` loops instead of `init; again: if (cond) goto over; body; end; goto again; over:`)

2026-10-11 08:47:24 UTC

- reply

reverse order when scope ends, it's not much more confusing than the last expression in a for loop, imo
(i also find it often clear than a sequence of goto cleanup_N; when you're dealing with more than one exit point)

2026-10-11 08:39:35 UTC

when's this whole "c is portable assembly" thing gonna end
it's just not

2026-05-19 00:06:05 UTC

- reply

only valve and nintendo are trying new things with controllers, tbh -- and valve is hitting it spot on with gyro and dual touchpads
i'm not a fan of a law requiring a specific controller layout at all, everything would become an xbox controller
if we have to have it, then i'd rather it be at most require adaptive icons in the ui like how steam does it, changing the displayed layout based on the controller being used, and nothing else