You are now blocking SIGINT whenever dd is not performing primary I/O. I don't think that's right.

Shorten man page, add UPDATING entry.

Fix brain glitch in man page.

BTW, I wonder if we should bump SHLIB_MAJOR. Is there an easy way to check?

No need for NO_WERROR now.

In D40226#916089, @khorben_defora.org wrote:

I did not need to change anything in usr.bin/drill to build; did I miss anything?

Fix gcc build as per @khorben_defora.org.

Remove man pages.

Fix type issue.

We still need <sys/param.h>.

See D40018 instead.

Remove unnecessary cast.

How does this differ from git arc stage?

Explain why shasum is commented out of the Makefile.

In D37404#905422, @gbe wrote:

Do you know a good mdoc replacement for the roff macros "\fI $String \fP"?

You seem to want to see some sort of conspiracy in this situation but have you considered the possibility that nobody wants to approve this review simply because _it's bad_?

Can confirm that it fixes the issue for me.

• In bits mode, check that the length is a multiple of 8.
• Remove unused test files.
• Don't install shasum for now.
• Improve the man page.

Check termination flag before blocking operations as well as after.

In D39641#906525, @kib wrote:

It seems that the easiest way to handle the issue is to block SIGINFO on the program start, then unblock it right before doing a syscall, and blocking after the return from syscall. This way you know that the signal delivery cannot interrupt any of the signal-unsafe function calls. The signal handler would print summary and terminate the process. Note that this is still not POSIX-compliant, but our implementation (as well as any reasonable Unix) guarantees that it is safe to do anything in signal handler if you did not interrupted not-async-signal-safe function.

In D39641#904361, @kib wrote:

Note that such signal handling makes the program behavior strange. Suppose that the signal was delivered in time when the code was executing, not during the read or write syscall. Then, you enter the next read/write call, and only after it returns, the new code reacts to the ctrl-C request. This would annoy users if they operate over a slow device.

See D39712#903737 for background.