This adds an MPI counterpart to the FLAG? MUF primitive. The check logic has been extracted into its own function.
Functionality
Both MPI and MUF versions check a single flag, which can be a prefix of a flag alias (regardless of object type). The check can also include any number of "!" characters on the left-hand side of the string for alternating negation.
This may be the first object-facing MPI function I've contributed, so let me know if I missed something there.
Consistency
This check now recognizes BOUND, HIDE, SETUID, and XPRESS as flag aliases. SET also was changed to recognize them.
Minor change
The code for FLAG? currently:
allows "" as the flag to check, and eventually returns 0.
allows "U" as the flag to check, and eventually returns 0.
does not allow "!" as the flag to check, and aborts with "Unknown flag"
This seems inconsistent, as the first two are similar conditions to the third. I've changed the third case to return 0 (with a bonus of returning 0 more quickly in the first case). I can see a corner case where one would want to abort when checking for "!", but it doesn't seem that compelling. Feel free to disagree, and I can change it to pass the error condition back to {flag?} and FLAG?.
This adds an MPI counterpart to the
FLAG?MUF primitive. The check logic has been extracted into its own function.Functionality
Both MPI and MUF versions check a single flag, which can be a prefix of a flag alias (regardless of object type). The check can also include any number of "!" characters on the left-hand side of the string for alternating negation.
This may be the first object-facing MPI function I've contributed, so let me know if I missed something there.
Consistency
This check now recognizes BOUND, HIDE, SETUID, and XPRESS as flag aliases.
SETalso was changed to recognize them.Minor change
The code for
FLAG?currently:This seems inconsistent, as the first two are similar conditions to the third. I've changed the third case to return 0 (with a bonus of returning 0 more quickly in the first case). I can see a corner case where one would want to abort when checking for "!", but it doesn't seem that compelling. Feel free to disagree, and I can change it to pass the error condition back to
{flag?}andFLAG?.