[sytelus]

Please do not do this! There is so much bad advice in this article. Remember the rule: Your code should be simple, but not simpler. There is absolutely no need to abandon great facilities afforded by language and libraries to make things unreadable, undebugable and unmaintainable.

[masklinn]

Abandoning some facilities does not "make things unreadable, undebugable and unmaintainable" and can allow them being used much more widely.

The limitations seem similar to #[no_std] in Rust, and while that's not something to strive for at all costs if you can do without it allows e.g. embedded developers or kernel/OS developers to use the work.

[berti]

> e.g. embedded developers or kernel/OS developers to use the work.

I certainly agree that's one of the strongest reasons to avoid allocating memory etc. It's pretty clear that not many commenters have done any work outside a hosted environment... but I guess that makes the point that we're in fairly specialised territory.

[matheusmoreira]

>great facilities afforded by language

Sometimes those aren't so great. For example, C has errno, a thread-local variable that gets set to the error code of the last function you called. Why can't the function just return the error code? I think it's strange how all the Linux system calls do return error codes but the standard library puts them in errno anyway.

I really like writing freestanding C because I can avoid most of the legacy.

[lgessler]

Don't you think using errno is a cleaner pattern? Conflating the place where you expect a value and the place where you check for a reason why no value could be produced can be dangerous. (E.g.: if the value is an integer, an error code is mistaken for a value.)

[matheusmoreira]

Linux returns negated errno constants. This produces error codes which are outside the range of valid values. I think it's more sane than errno.

Functions of my own design almost always return status codes only. Actual data is returned through pointer parameters. This allows me to quickly determine the exact set of variables that are affected by any function call.

[abiox]

could you be a bit more specific about what you feel is "bad advice"?

[chris_wot]

I don't think he's saying to do this in every library, it's just an interesting technique he uses for very minimalist libraries.