[kunpai]

Abort on an unknown output format in ZopfliCompress, as C does

Problem

ZopfliCompress (C, Rust) switches on the output format. C handles gzip, zlib and deflate, and for anything else asserts. The build has no NDEBUG, so assert(0) aborts the process. The port matches formats 0, 1 and 2 and for any other value returns an error, which its compress helper turns into a silent no-op: nothing is written and the call returns normally. For example, calling ZopfliCompress with output_type = 64:

	C	Rust
output_type 64	assert(0) fails, the process aborts (SIGABRT)	returns with no output written, as if it succeeded

Question

Which behaviour do we want: C's or the Rust port's? Specifically, for an output format C does not recognise, should ZopfliCompress abort (like the C source), or return quietly without writing anything (like the Rust port)?

This PR implements C's behaviour.

Fix

Rust_ZopfliCompress's unknown-format arm calls std::process::abort() in place of returning an error:

-            _ => Err(crate::error::Error::TooFewMaxBits),
+            _ => std::process::abort(),

Replayed on the output_type = 64 record, before and after:

	C	Rust main	Rust patched
trap	SIGABRT (6)	none (returns, writes nothing)	SIGABRT (6)

Both sides now abort, and the divergence closes.

Downstream check. The normal path is untouched: ZopfliGzipCompress on the repository's README gives the same 831-byte stream from the port before and after this patch, and gzip.decompress restores the file. C's stream is also 831 bytes but differs in a few bytes, for a separate reason (#213).

Notes for review:

• This changes a no-op into a process abort. That is what C does, but it is a behavior change for any caller that today passes an out-of-range format and relies on the quiet return. Returning an error (the port's current choice) or aborting (C's) are both defensible; the PR only makes the two sides agree so the question can be decided.