News for hackers. Stuff that matters.
Re:Pledge() and unveil() in SerenityOS (2020) by IshKebab on Friday July 15, 2022 @02:58PM (#32111615)
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.
Re:Pledge() and unveil() in SerenityOS (2020) by jeshin on Friday July 15, 2022 @07:04PM (#32113669)
if you really care about static type checking, you probably wouldn't be using C
Re:Pledge() and unveil() in SerenityOS (2020) by IshKebab on Saturday July 16, 2022 @02:19AM (#32115689)
You probably would if you care about static typing and are working on a kernel syscall interface.
Re:Pledge() and unveil() in SerenityOS (2020) by jeshin on Sunday July 17, 2022 @02:49AM (#32124979)
and yet they chose to use strings for their api, eh?
Re:Pledge() and unveil() in SerenityOS (2020) by IshKebab on Sunday July 17, 2022 @02:43PM (#32129762)
Well exactly. That's why it's so weird.