I'm not sure but it seems that on the changed lines you replaced space indentation with tabs.

As of stable/14 this no longer compiles for me due to

/usr/src/lib/libcmb/cmb.c:854:6: error: invalid argument type 'void' to unary expression
        if (!BN_zero(count))
            ^~~~~~~~~~~~~~~
/usr/src/lib/libcmb/cmb.c:1032:7: error: invalid argument type 'void' to unary expression
                if (!BN_zero(seq))
                    ^~~~~~~~~~~~~
2 errors generated.

1. -D doesn't imply -d anymore. I found that to be unnecessarily limiting, now users can decide on the visual format.
2. The usage output and the manual page are updated.

Add -D both.

Follow advice from Jamie and use -D up and -D down.

Address comments from Jilles.

If it's just an effort to synchronize with OpenBSD then I vote against this change. I intentionally removed this option years ago, so I have to assume that the difference here comes from the fact that OpenBSD didn't.
If, however, you want to restore this functionality for whatever reason, I will only make a face and accept it.

What are the functions? Generally, passing a null pointer to a standard string function invokes UB regardless of the passed size, and some compilers do make optimizations based on this assumption.

Reduce code duplication.
I was worried about some repetitive code here when adding the second source of commands (built-ins, after files from $PATH), but it became visibly worse when I started working on adding a third source (aliases). So the sooner I factor this out, the cleaner the future commits will be.

Address reviews.

builtincmd doesn't hold C strings, use memcmp().

This doesn't follow the Don't Repeat Yourself principle, but currently I don't have a better idea how to express this code.

My question about fprintf() remains unanswered, but it is not a blocker.

TODO: write the manpage

Minor style improvements, nitpicking and questions.

Please provide more diff context (diff -U999999).

Back out the previous update.
The -1 was there for the i++ that the loop always performs, so it's needed regardless of whether strftime() returned 0 or more.
Split the calculation that was there before into two parts, one of which just decrements i and makes a comment on why it's done.

Minutes after posting the previous version, I thought about handling the rare corner case when strftime() returns 0.

Simplify the code part a bit.
Also improve comments and some variable names.

When I was looking at this code today, I thought that the unconditional memccpy() is a bit wasteful in the \D{} case, because the one copied byte is a special case and when it's noticed, the copied byte is overwriten by strcpy() with "%X".
There is little to be gained in either performance or legibility of the code, but when I rewrote this locally to be less wasteful, it didn't look much worse, nor did it look much better.
Opinions?

In this iteration I tried to address all new feedback.
I also was annoyed by the current formatting of the file, so this is a diff against D37926 where I reduce indentation.

Drop PS4 support and update the manual page changes according to feedback.

In D37753#860082, @stevek wrote:

Hi, thanks for working on this.

LGTM FWIW

Should this version become the default? On the one hand, it has POLA violation potential, on the other hand, it's what the command does under another system.

Initial review.

hw: column width ((h)ard (w)idth?)

If you intend to do more work on these files, I suggest improving the style before introducing more significant changes. There is a lot of inherited stylistic issues here, unfortunately.
I think you have a typo in the description and you meant "braces" - I meantion it just in case you planned to copy it to the commit message.

Would it be possible to omit the compat subdirectory from the import?

@kib, sorry about not providing some aspects of the context of this change, I thought this was a good enough draft to get the first few reviews, but in hindsight it looks just lazy of me.

But the summary contains the same phrase twice, seems unintentional.

Please remember to tag the commit as Relnotes: yes.

In D35807#823735, @obiwac_gmail.com wrote:

Where can I find the rules for vertical spacing? I can't find it explicitly in style(9)

In D35807#823358, @obiwac_gmail.com wrote:

I can do it myself this evening, if that doesn't slow you down for anything else. (Aswell as making that post on -hackers that @lwhsu mentioned, if that's still necessary.)

@jilles is this patch in a good shape now?

In D35807#815011, @obiwac_gmail.com wrote:

Hey guys, is there anything here that I still need to do?

I already started looking into adding it to prevent my cat from powering off my system