> The elegance of the fork() + exec() model is that every kind of configuration can be done after the fork using all the usual APIs. Unfortunately, the opposite is true, when the parent process is multi-threaded. In the…
I have no love lost for Wayland, but this: > Make easy things easy. Make hard things doable. is generally unachievable. Instead, pick one: - easy things easy, hard things impossible - easy things tedious, hard things…
> It does not matter which is the relationship between the sizes of such types, there will always be values of the operand that cannot be represented in the result. It's not that bad actually; not "always". The only…
Everybody seems to be missing the forest for the trees on this. There is absolutely no "sign extension" in the C standard (go ahead, search it). "Sign extension" is a feature of some assembly instructions on some…
One of the most fascinating and moving writings I've read in my life.
Exactly; I can't understand this obsession with header-only C "libraries".
> The elegance of the fork() + exec() model is that every kind of configuration can be done after the fork using all the usual APIs. Unfortunately, the opposite is true, when the parent process is multi-threaded. In the…
I have no love lost for Wayland, but this: > Make easy things easy. Make hard things doable. is generally unachievable. Instead, pick one: - easy things easy, hard things impossible - easy things tedious, hard things…
> It does not matter which is the relationship between the sizes of such types, there will always be values of the operand that cannot be represented in the result. It's not that bad actually; not "always". The only…
Everybody seems to be missing the forest for the trees on this. There is absolutely no "sign extension" in the C standard (go ahead, search it). "Sign extension" is a feature of some assembly instructions on some…
One of the most fascinating and moving writings I've read in my life.
Exactly; I can't understand this obsession with header-only C "libraries".