Also the usage of strings for flags and not int bits just let me cry out. This is pure nonsense.
There's nothing wrong with the use of strings here. It's very readable, easily understandable to anyone who knows C, can be checked by automated tools (or at runtime) for invalid values, and is easily extensible in the future. It's also not on a hot path (I mean, you shouldn't have to do this at any point other than process creation).
Now, at a language level, would I like the C committee to start looking at some of these things? Yes, but why bother hoping for miracles.
1) https://www.engadget.com/2018/07/13/aliens-colonial-marines-...
1) easily readable, string-like input; 2) built-in-your-code verification and 3) compile-time check; 4) zero-overhead execution.
Just reading Ted‘s blog post gave me an idea how lang-specific libraries / (thin-layer) abstractions (or simply additional magic helper functionality) can improve upon legacy API designs (e.g. the GLX example) by using lang-specific functionality I never knew I‘d need or even cared about. Sometimes one can learn when you‘d never expect it. :D
Unless I‘m mistaken and misunderstood the whole thing, please correct me in that case.
Makes the calls shorter and easier to read. Consider:
if (pledge("stdio rpath tmppath proc exec", NULL) == -1)
err(1, "pledge");
if (pledge(PLEDGE_STDIO | PLEDGE_RPATH | PLEDGE_TMPPATH | PLEDGE_PROC | PLEDGE_EXEC, NULL) == -1)
err(1, "pledge");
And really, unless you're using pledge wrong, ie. by using it outside of the startup path and/or not checking the return value, what does compile-time checking get you?