[vageli]

You don't see an issue with needing to write and maintain a verification script for something that is essentially a solved problem? Why add more development runtime overhead? What do string-based flags get you that bit-based don't?

[temprature]

Removes the need to add a separate include for namespacing, ie. no pledge.h header needed.

Makes the calls shorter and easier to read. Consider:

    if (pledge("stdio rpath tmppath proc exec", NULL) == -1)
        err(1, "pledge");

vs.

    if (pledge(PLEDGE_STDIO | PLEDGE_RPATH | PLEDGE_TMPPATH | PLEDGE_PROC | PLEDGE_EXEC, NULL) == -1)
        err(1, "pledge");

Makes it easier to add a pledge interface to other languages with having to keep chasing bit flag changes, ie. there's been several new promises add since 2015 but the OpenBSD::Pledge perl module hasn't needed to change.

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?

[protomyth]

Nope, I really don't. I don't fear strings in code because I have to run verification scripts on whatever config format we end up using or you get stuff like [1]. Its just another part of the compile process once setup, and their reasoning was sound[2], so why stress. Heck, the script isn't even complicated.

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-...

2) https://www.tedunangst.com/flak/post/string-interfaces

[fbender]

If I’m not mistaken, you can even have the best of both worlds in languages with proper macro support (I’m sure you know which lang I‘m talking about): The Macro call can take the string input and „desugar“ it into bitmasks / function calls / whatever you need at compile time. Then you have:

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.

[protomyth]

I think the issue is that for most languages you have to update the libraries with the new constants for bit-wise operations and not for the string approach. Some languages would be fine, but this is multi-language in the end.