The previous version failed for names that required exactly n*13+1 UTF-16 symbols (e.g. 123456🤐1234🤐) and had a surrogate pair at the end of the name.
This problam was detected by running the msdos24.sh test script recently added to the stress2/misc directory.
The cause was that the end of the unix name had been seen, which made unix2winfn() return end == true, but there still was a surrogate value that required another invocation of unix2winfn() to be written to the next directory slot.

I have found that the test added to the stress2/misc directory to specifically test filenames with surrogate pairs (msdos24.sh) reports errors.
When restricted to just ASCII file names or UTF-16 symbols without surrogate pairs, the test succeeds.

I have committed 3 new tests in tools/test/stress2/misc (msdos22.sh, msdos23.sh, msdos24.sh), since I found that msdosfs with the patches in this review failed "under load" when running these tests (originally the script that has been committed as msdos24.sh).

In D57313#1313421, @mckusick wrote:

Have you run your suggested tests?

In D56511#1295639, @des wrote:

In D56511#1295534, @se wrote:

I plan to commit these patches after some more testing

I don't think you understand how Phabricator works...

Thanks for pointing out the typo in dc_tests.sh.
I can see that this typo makes the test fail on the build cluster, when run under an account without write access to /usr/tests/usr.bin/gh-bc.
It worked on my machine when run as root, but that's no excuse ...
I plan to commit these patches after some more testing (for some reason depends_cleanup.sh is not executed during buildworld, but the tests obj directory is removed in stage 2.2, anyway).

The author of this BC / DC has asked me to not create a fork.
The typo in all.sh has been reported by me and fixed in upstream commit 3887cc1.
The author offered to tag a version 7.1.1, but since it did not affect FreeBSD (usage() in all.sh is not used on FreeBSD, since valid parameters are being passed), I did not ask for it.
The script tests are only relevant for the port, since they depend on a previous version of BC / DC installed on the system the test is run on.
Since no previous version can be assumed to exist on the base system, there is no way to generate the expected outputs from a binary other than the one to be tested.

The tests complete in 3 seconds on my amd64 system.
I do assume that the 100 times slower execition on riscv64 is due to inefficient emulation of that platform?
Instead of patching the timeout in individual ports, I believe the parameters in the CI system should be adjusted to account for the slow execution speed of emulated systems.
Therefore, I do not want to set the timeout to such a high value for all platforms.
If there is consensus that changing individual ports is required, I'd make the timeout adjustment depend on the architecture (apparently, only riscv64 is affected).

Looks fine.

Update diff to be in standard format (had been created with "diff.mnemonicprefix=true").