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).
Right but is there really any reason why the implementation should call strncmp or anything that would be costlier than a bitwise AND? It's not like "r" reads better than O_RDONLY.
Pledge happens on process startup only, so since it’s not like it is called over and over again during the life of the process, the overhead is certainly negligible for all modern servers, desktops and laptops.
It's also pretty trivial to run the program. Maybe it's different in other projects, but I'm pretty sure in OpenBSD you're encouraged to actually test the code, not just ship it because it compiles. There's 2 programs in OpenBSD's base that don't abort on the pledge call failing, they're both shells, and they don't fail quietly.
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?
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).