[Toaster-King]

There's a great blog post[1] by one of the OpenBSD developers about why they did so. tl;dr using bitmasks necessitates namespaced enums/defines that take up horizontal space, strings are easier and don't need to go through the C pre-processor.

[1] https://flak.tedunangst.com/post/string-interfaces

[IshKebab]

Nice find. That article is highly unconvincing though and mostly argues against straw men.

> Although using strings subverts C’s already weak type checking, that’s probably not a major concern. One can screw up bit masks by using || in place of |. Or, as above, one can incorrectly pack the magic array. It’s usually much easier to visually audit a string than the C code used to plaster a dozen option together.

It's pretty easy to design an interface that is way way less error-prone than strings (especially ones full of single-letter differences!) and the visual auditing argument falls apart as soon as you have to `snprintf()` some string together from parts.

This code is way more readable, way less error prone, more discoverable, faster and more easily extendable than strings:

    auto config = make_pledge_config();
    config.read_path = true;
    config.stdio = true;
    pledge(&config);

You'd think security focused people would care about static type checking.

[jeshin]

if you really care about static type checking, you probably wouldn't be using C

[IshKebab]

You probably would if you care about static typing and are working on a kernel syscall interface.

[jeshin]

and yet they chose to use strings for their api, eh?

[IshKebab]

Well exactly. That's why it's so weird.

[hag]

Nice! I would probably have used bitmasks in this situation, but as usual there is a reason behind the choice and I get the reasoning.

[agileAlligator]

great find!