>> I have attached a patch to this email that modernizes pax/tar to match
>> POSIX.1-2024 and adds a comprehensive -o keyword framework.
> 
> [ ... ]
> 
> For such extensive modifications to a critical program in base, you really
> want to split the diff up in to smaller chunks.  An exception to this might be
> if you're just showing 'work in progress' to get some early feedback, but this
> doesn't seem to be the case here.

Yes, it's a work in progress that I started without a clear reason. I'm 
new to systems programming, and because of my severe OCD 
(obsessive-compulsive disorder), I often throw myself into doing things 
to calm the anxiety of my obsessions. After spending a lot of time on 
them, I realize that they don't make much or any sense. Recently it was 
TV series; now it's OpenBSD. The fact is, I've grown tired of continuing 
with this and am sending the code in case it's useful to anyone. I 
should have mentioned this in my first email. Sorry for the inconvenience.

> 
> Also, there are regression tests for pax in src/regress/bin/pax.  It's useful
> to mention that your changes pass the existing regress tests, (if you read
> posts to -tech over a period of time, you'll see this quite frequently).
> 
> (Once new features are accepted, it might even be worth proposing new regress
>   tests relevant to them, although this is by no means essential.)
> 
> Your changes to the standards section of the manual page change it to say that
> pax is now compliant with the spec.  Although you have indeed have added
> support for the functions that were obviously missing, have you actually
> checked that the existing code is 100% compliant, and that this claim is
> valid?
> 
> (Some time ago during recent changes to pax, there was a discussion about how
>   to handle character encodings, my understanding is that either a decision was
>   taken to specifically not follow the spec to the letter, or there was not
>   full agreement between everyone about what the spec was actually demanding.)
> 
> Finally, remember that a new -release is just around the corner.  This
> probably isn't a great moment to propose such a large change.
>