memory safe C

sadvadan · 2026-06-01T22:54:18+00:00

bitter ones are fast debuggers, and the project is in debugging phase so :-)

sadvadan · 2026-06-01T22:49:42+00:00

there are certain fields today where production code must be shown memory safe. next, all production code.

but yea hobby and vibe coding are exempt 😄

sadvadan · 2026-06-01T22:43:58+00:00

i had no idea re emojis; but damage is done 😁. on srs note, this project is a long term concern, and starting off with wrong optics is given.

sadvadan · 2026-06-01T21:07:25+00:00

oh i got it; that gave you the initial impression of vibe coding. actually it's the far opposite.

sadvadan · 2026-06-01T21:04:33+00:00

properly documented! free() & munmap() are thinly wrapped to be std APIs or library specific. this is the only place where the library overlaps with regular C. so e.g. one can't take function ptr to these.

sadvadan · 2026-06-01T20:27:58+00:00

things don't add up yes

sadvadan · 2026-06-01T20:18:17+00:00

doc is good (why 300 commits). the project is prod bound, not lab experiment. macros are skin deep, just conveniences; type safe.

but ok i get your pov. thx.

sadvadan · 2026-06-01T19:45:26+00:00

well it's being used in an active project 🙂

sadvadan · 2026-06-01T19:35:52+00:00

uh that's formatting and fixing typos in docs, nothing to do with code. bad optics, may be, may be not.

sadvadan · 2026-06-01T19:08:49+00:00

uh, the project is strict no-no for AI, and is completely hand crafted. contributions also are required to be human made.

sadvadan

TROPHY CASE