I'm really sorry for ignoring this for so long. Someone asked me about
the `argv0 = *argv, argv0 ? (argc--, argv++) : (void *)0;` one-liner,
and I remembered this patch. I finally took the time to investigate
this issue in more detail.

On 2018-07-08, Mattias Andrée <maandree_AT_kth.se> wrote:
> In POSIX-2017 it was clarified via the documentation for
> basename(1) and dirname(1) that all programs should support
> -- unless specified otherwise.

As far as I know, unless the documentation states that a utility shall
conform to the Utility Syntax Guidelines, it is not required to
support `--`. However, it does use the language "should" which
means[2]:

For an implementation that conforms to POSIX.1-2017, describes a
feature or behavior that is recommended but not mandatory.

It looks like these tools formerly supported `--`, but this was
removed in 9016d288[3], with the justification that echo(1) is
mandated to *not* support `--` and that there is no reason why other
tools with no options should handle it. I would argue that there *is*
a reason to support `--`, and that is the Utility Syntax Guidelines.
echo(1) is an exception that is explicitly called out, but a single
exception shouldn't set a precedent for other tools. In fact, tty(1)
is actually required to support the Utility Syntax Guidelines[4], so
9016d288 actually breaks POSIX conformance. The examples you mentioned
in basename(1) and dirname(1), and also a note about `--` I found in
expr(1) seem to support this view.

Rather than add a special ENOFLAGS macro, I am tempted to revert
9016d288 instead. The question that remains is how to handle arguments
that look like options (start with `-`) for tools that don't have any
specified options. It seems for some tools it is important to treat
them as operands (e.g. printf, expr), but for others that are commonly
extended with additional options, it might make sense to fail with
usage() to catch unsupported uses (e.g. hostname, tsort, chroot).