Either way, formatting shouldn't be done manually, and I can't approve this until there's a way to do it automatically.
Indenting this sucks and looks ugly even in practice. See my criticisms in the style guide.
This looks like I threw my code line through an AI blender. The bits should be next to the hex, separate from the unrelated comment. This statement is missing a semicolon.
That's because the amount of data in total that will be written is totally irrelevant to -B.
It should be highlighted that the input buffer should be very large (e.g. 4M) to take advantage of modern hardware I/O speeds, and for most uses mm(1) is better.
Again, this commenting is bad. C isn't its preprocessor. If this kind of commenting is needed I would straight-up rather remove C from this project than continue with it. The alternative to do/whiles is infinite loops with conditions at the end which are what do/whiles exist to solve. Commenting the function of basic C language features clutters code significantly.
Moving this comment makes it wrong. This ternary makes sure strtol(3p) succeeded. *s == 0, which is on its own vague, checks if no chars are left unparsed.
getopt(3p) will still happen when argc==0. And dj(1) should run when argc<0. If the user's system is broken, don't deny them the basic tools to fix it.
This shouldn't be required. Typos are easy to spot in Rust and I believe C disallows this.
This is what indentation is for. This introduces extra complexity to program maintenance - what if the command and while statement are mismatched? It's less important to know the constraints of repetition in a do/while because the code inside will always run at least once; the while constraint is only on subsequent runs.
This stands to clutter code significantly. I guess because Rust does it, it makes sense for this project, but C programmers who do this bug the hell out of me.