GeezerVison

how did you get - 3?
it's not in the manual, so where does this value come from?

I found it by testing GNU diff 3.12, GNU accepts the one ending in …804 and rejects the one ending in …805. happy to change the exact limit if you want

this doesn't fix the crash, it just moves it
-t --tabsize=9223372036854775804 with a tab in the input still aborts in do_expand_tabs (with_capacity + ntabs * (tabsize - 1) overflow)
could you please fix do_expand_tabs instead (no huge preallocation, write the spaces as a stream)?

You're right, it did just move the crash. I've changed do_expand_tabs the way you suggested: it no longer reserves a big block of memory up front, and it writes the spaces in small chunks. One thing it doesn't fix yet is that diff still holds its whole output in memory, so a big enough value will still run out of memory at some point. Do you want me to stream the whole output in this PR, or leave that for a separate follow-up?

is -t needed here?

No, it isn't, so I've removed it. The value gets rejected before any input is read, and GNU rejects it without -t as well.

the value is rejected while parsing, so looping over the formats doesn't test anything more, no?
please add a test with a value below the limit and a tab in the input, that's the one that crashes

I agree, the loop didn't add anything, so I've removed it. In its place I added a test that calls do_expand_tabs directly with a tab and a huge value just below the limit. It finishes instantly without crashing. A full end-to-end test would need the output to stream first, so that depends on what you decide about my question in the other thread.

i guess the - 3 is so that t + GUTTER_WIDTH_MIN in side_diff Config::new doesn't overflow isize?
if so, please say that here instead of "matching GNU diff"

Yes, that's exactly it. GUTTER_WIDTH_MIN is 3, and side-by-side mode computes tabsize + 3 as an isize. So isize::MAX - 3 is the largest tabsize that doesn't overflow; one higher panics with "attempt to add with overflow".

I updated the comment to say that, and that GNU accepts the same maximum. I also added a unit test that sets up side-by-side mode with tabsize at isize::MAX - 3, so if the limit changes the test will catch it.

do we need this writer?
&mut [u8] (e.g. &mut [0u8; 1000][..]) already fails with WriteZero once full

No, we don't. I removed it. The test now writes into a plain 1000-byte buffer, which already fails with WriteZero when it fills up, and the check is the same as before.

neither value is below the limit, so this doesn't test what the parser accepts
could you please use MAX_TABSIZE?

Done. The test now uses MAX_TABSIZE, the largest value the parser accepts, instead of a hard-coded number.