fix(io-compression): the three streams enforce their own mode (#2152)

DeflateStream, GZipStream and ZLibStream now reject a Read on a Compress-mode
stream and a Write on a Decompress-mode stream with InvalidOperationException,
matching .NET's EnsureDecompressionMode/EnsureCompressionMode
(DeflateStream.cs:387-403) and carrying SR.CannotReadFromDeflateStream /
SR.CannotWriteToDeflateStream verbatim (Strings.resx:122,125).

THE READ ROW IS THE ONE THAT MATTERED. It used to return 0 -- indistinguishable
from end-of-stream -- so a read loop over a Compress-mode stream terminated
normally having produced nothing, with no diagnostic anywhere. The Write row
already threw, but named zlib's internal Z_STREAM_ERROR ("deflate error -2") for
what is a caller mistake.

A caller that checks CanRead/CanWrite is unaffected; those properties already
reported the right answer, which is exactly why the defect was invisible.

THE ORDER IS TRANSCRIBED, NOT CHOSEN. .NET runs ValidateBufferArguments in
Read(byte[],int,int) and then ReadCore opens with EnsureDecompressionMode()
followed by EnsureNotDisposed() (DeflateStream.cs:284-309; Write is the same shape
at :531-570). So arguments, then mode, then disposed -- and a stream that is BOTH
disposed and in the wrong mode reports the MODE. One existing test asserted the
opposite for a Compress-mode Read and is updated rather than worked around.

A MUTATION PROVED THE EXCEPTION TYPE ALONE CANNOT EXPRESS THAT ORDERING.
ObjectDisposedException derives from InvalidOperationException here as it does in
.NET, so EXPECT_THROW(..., InvalidOperationException) is satisfied by BOTH orders
and the swapped-order mutation went uncaught. The message is the only
discriminator, so the message is what the test asserts. Recorded rather than
quietly fixed.

FLUSH DELIBERATELY GETS NO GUARD. .NET's Flush() opens with EnsureNotDisposed()
alone and then no-ops for a Decompress-mode stream (DeflateStream.cs:210-215).
Adding one would be a plausible-looking symmetry the reference does not have, so a
test pins its absence.

A CORRECTION MADE ON THE WAY PAST. ThrowInvalidCompressionMode's doc-comment
recorded that #2148 chose the base ArgumentException from the audit's managed probe
and that "/rv is absent here to narrow it further". /rv is present now and confirms
the choice exactly: DeflateStream.cs:99 is
`throw new ArgumentException(SR.ArgumentOutOfRange_Enum, nameof(mode))`, and
ArgumentOutOfRange_Enum is "Enum value was out of legal range." -- same type, same
message, same parameter name. The caveat is replaced by the measurement.

Two pins inverted, four cases added (IO_Compression 101 -> 103). Five mutations,
all caught -- one only after the ordering test stopped asserting a type and started
asserting a message.

Downstream, measured per SA-2 condition 5: neither cna nor mobile-eggbert
references any of the three stream types -- zero sites in both. Neither modified.

Gate: 17,304 run, 17,304 passed, 0 failed, 0 skipped across 38 executables, GREEN.

docs/Migration-CompressionStreamModeGuards.md

Author: robertvokac

CLAUDE.md

@@ -0,0 +1,111 @@
+<!-- SPDX-License-Identifier: MIT -->
+<!-- Copyright (c) Robert Vokac and contributors -->
+
+# Migration — the compression streams enforce their own mode (ticket #2152)
+
+*2026-08-18.* `DeflateStream`, `GZipStream` and `ZLibStream` now reject a `Read` on a
+Compress-mode stream and a `Write` on a Decompress-mode stream with
+`InvalidOperationException`, matching .NET.
+
+Landed under `docs/StandingApprovals.md` SA-5. No signature, layout or `noexcept` change.
+
+---
+
+## 1. What changed
+
+| Call | Was | Is |
+|---|---|---|
+| `Read` on an open **Compress**-mode stream | returned **0** | `InvalidOperationException("Reading from the compression stream is not supported.")` |
+| `Write` on an open **Decompress**-mode stream | `IOException("DeflateStream: deflate error -2")` | `InvalidOperationException("Writing to the compression stream is not supported.")` |
+| `Read` on a **closed Compress**-mode stream | `ObjectDisposedException` | the **mode** error — see §3 |
+| `Write` on a **closed Decompress**-mode stream | `ObjectDisposedException` | the **mode** error |
+| `Flush()` in either mode | no mode guard | **no mode guard** (unchanged, deliberately — §4) |
+| every call in the mode that allows it | — | **unchanged** |
+
+**The `Read` row is the one that mattered.** Returning 0 is indistinguishable from end-of-stream,
+so a read loop over a Compress-mode stream terminated normally having produced nothing, with no
+diagnostic anywhere. The `Write` row already threw; it just named zlib's internal `Z_STREAM_ERROR`
+for what is a caller mistake.
+
+A caller that checks `CanRead`/`CanWrite` first is unaffected — those properties already reported
+the right answer, which is exactly why the defect was invisible.
+
+## 2. The reference
+
+```csharp
+private void EnsureDecompressionMode()
+{
+    if (_mode != CompressionMode.Decompress) ThrowCannotReadFromDeflateStreamException();
+    static void ThrowCannotReadFromDeflateStreamException() =>
+        throw new InvalidOperationException(SR.CannotReadFromDeflateStream);
+}
+```
+*(`DeflateStream.cs:387-395`; `EnsureCompressionMode` is the mirror at `:396-403`.)*
+
+The two messages are `Strings.resx:122,125` verbatim. They name *"the compression stream"* rather
+than a concrete type, so all three wrappers share one string — which is what .NET does too, since
+`GZipStream` and `ZLibStream` delegate to `DeflateStream`.
+
+## 3. The order is transcribed, not chosen
+
+```csharp
+public override int Read(byte[] buffer, int offset, int count)
+{
+    ValidateBufferArguments(buffer, offset, count);      // 1. arguments
+    return ReadCore(new Span<byte>(buffer, offset, count));
+}
+
+internal int ReadCore(Span<byte> buffer)
+{
+    EnsureDecompressionMode();                            // 2. mode
+    EnsureNotDisposed();                                  // 3. disposed
+```
+*(`DeflateStream.cs:284-309`; `Write`/`WriteCore` is the same shape at `:531-570`.)*
+
+So a stream that is **both** disposed and in the wrong mode reports the **mode**. That is a
+behaviour change for one existing test, which is updated rather than worked around.
+
+**A mutation proved the type alone cannot express this.** `ObjectDisposedException` derives from
+`InvalidOperationException` — here as in .NET — so `EXPECT_THROW(…, InvalidOperationException)` is
+satisfied by *both* orders and the swapped-order mutation went uncaught. The message is the only
+discriminator, so the message is what the test asserts.
+
+## 4. `Flush()` deliberately has no guard
+
+.NET's `Flush()` opens with `EnsureNotDisposed()` alone and then no-ops for a Decompress-mode
+stream (`DeflateStream.cs:210-215`). Adding a mode guard there would be a plausible-looking
+symmetry the reference does not have, so a test pins its absence.
+
+## 5. A correction made on the way past
+
+`ThrowInvalidCompressionMode`'s doc-comment recorded that #2148 chose the **base**
+`ArgumentException` from the audit's managed probe and that *"`/rv` is absent here to narrow it
+further"*. `/rv` is present now and confirms the choice exactly: `DeflateStream.cs:99` is
+`throw new ArgumentException(SR.ArgumentOutOfRange_Enum, nameof(mode))`, and
+`ArgumentOutOfRange_Enum` is *"Enum value was out of legal range."* — same type, same message,
+same parameter name. The caveat is replaced with the measurement.
+
+## 6. To migrate
+
+```cpp
+// A stream opened to compress can only be written; one opened to decompress can only be read.
+if (stream.getCanReadProperty()) { /* … Read … */ }
+```
+
+`CanRead` and `CanWrite` have always reported this correctly. Code that branched on them needs no
+change; code that did not now gets a diagnostic instead of silence.
+
+## 7. Evidence
+
+| Mutation | Caught |
+|---|---|
+| Drop the read-mode guard (one stream type) | ✅ |
+| Drop the write-mode guard (one stream type) | ✅ |
+| Run the mode check **after** the disposed check | ✅ — **only after** the test asserted the message; the type alone could not see it |
+| Add a mode guard to `Flush()` | ✅ |
+| Swap the two messages | ✅ (2 tests) |
+
+## 8. Downstream, measured
+
+Per SA-2 condition 5: neither `cna` nor `mobile-eggbert` references `DeflateStream`, `GZipStream`
+or `ZLibStream` — **zero sites in both**. Neither repository was modified.

docs/Migration-CompressionStreamModeGuards.md

@@ -92,18 +92,76 @@ namespace System::IO::Compression::Detail {
     /**
      * @brief Throws `ArgumentException("Enum value was out of legal range.", paramName)`.
      *
-     * The **base** `ArgumentException`, not the derived `ArgumentOutOfRangeException`, because the
-     * audit's own managed probe for SR-AUD-258 recorded the category .NET reports for this exact
-     * call as `ArgumentException` (`audit/.../DeflateStream.cpp.audit.md`, "current .NET prints
-     * `invalidMode=ArgumentException`"), and `/rv` is absent here to narrow it further. Same
-     * choice, for the same reason, as `System::Threading`'s `EventWaitHandle` (#1954) and
-     * `System::Uri`'s `Uri(string, UriKind)` (#1992).
+     * The **base** `ArgumentException`, not the derived `ArgumentOutOfRangeException`. #2148 chose
+     * this from the audit's own managed probe and recorded that `/rv` was absent to narrow it
+     * further. **It is present now, and it confirms the choice exactly**: `DeflateStream.cs:99` is
+     * `throw new ArgumentException(SR.ArgumentOutOfRange_Enum, nameof(mode))`, and
+     * `ArgumentOutOfRange_Enum` is *"Enum value was out of legal range."* — the same type, the same
+     * message and the same parameter name. Verified 2026-08-18 by ticket #2152.
      */
     [[noreturn]] void ThrowInvalidCompressionMode(const char* paramName);
 
     /** @brief Throws `ObjectDisposedException(typeName, "Cannot access a closed Stream.")`. */
     [[noreturn]] void ThrowStreamClosed(const char* typeName);
 
+    /**
+     * @brief Throws `InvalidOperationException("Reading from the compression stream is not supported.")`.
+     *
+     * .NET's `SR.CannotReadFromDeflateStream`, transcribed
+     * (`System.IO.Compression/src/Resources/Strings.resx:122`). The message names *the compression
+     * stream* rather than the concrete type, so all three wrappers share one string, exactly as
+     * .NET's three do — `GZipStream` and `ZLibStream` delegate to `DeflateStream` there.
+     */
+    [[noreturn]] void ThrowCannotReadFromCompressionStream();
+
+    /**
+     * @brief Throws `InvalidOperationException("Writing to the compression stream is not supported.")`.
+     *
+     * .NET's `SR.CannotWriteToDeflateStream` (`Strings.resx:125`).
+     */
+    [[noreturn]] void ThrowCannotWriteToCompressionStream();
+
+    /**
+     * @brief Rejects a read on a stream that was opened to **compress**.
+     *
+     * Ticket #2152 (SR-AUD post-audit, measured under #2148 and deliberately left then). Before it,
+     * a `Read` on an open Compress-mode stream returned **0** — a silent wrong answer a caller
+     * cannot distinguish from end-of-stream — and a `Write` on an open Decompress-mode stream
+     * surfaced zlib's `Z_STREAM_ERROR` as `IOException("DeflateStream: deflate error -2")`, naming
+     * an internal error code for a caller mistake. .NET guards both
+     * (`DeflateStream.cs:387-403`).
+     *
+     * **The position matters and is transcribed rather than chosen.** .NET runs
+     * `ValidateBufferArguments` in `Read(byte[], int, int)`, then `ReadCore` opens with
+     * `EnsureDecompressionMode(); EnsureNotDisposed();` — in that order (`DeflateStream.cs:284-309`).
+     * So the mode check sits **between** the argument validation and the disposed check, and a
+     * *disposed* Compress-mode stream reports the **mode** error, not `ObjectDisposedException`.
+     *
+     * `Flush()` deliberately gets **no** guard: .NET's opens with `EnsureNotDisposed()` alone and
+     * then no-ops for a Decompress-mode stream (`DeflateStream.cs:210-215`).
+     *
+     * @throws System::InvalidOperationException when @p mode is not `Decompress`.
+     */
+    inline void EnsureDecompressionMode(CompressionMode mode) {
+        if (mode != CompressionMode::Decompress) {
+            ThrowCannotReadFromCompressionStream();
+        }
+    }
+
+    /**
+     * @brief Rejects a write on a stream that was opened to **decompress**.
+     *
+     * The mirror of EnsureDecompressionMode; see that function for the ordering rule and for what
+     * each door did before ticket #2152.
+     *
+     * @throws System::InvalidOperationException when @p mode is not `Compress`.
+     */
+    inline void EnsureCompressionMode(CompressionMode mode) {
+        if (mode != CompressionMode::Compress) {
+            ThrowCannotWriteToCompressionStream();
+        }
+    }
+
     /**
      * @brief Rejects a `CompressionMode` outside the two members the enum declares.
      *

modules/io-compression/include/System/IO/Compression/CompressionArgumentValidation.hpp

@@ -6,6 +6,7 @@
 #include "System/ArgumentNullException.hpp"
 #include "System/ArgumentOutOfRangeException.hpp"
 #include "System/ObjectDisposedException.hpp"
+#include "System/InvalidOperationException.hpp"
 
 #include <zlib.h>
 
@@ -37,6 +38,18 @@ namespace System::IO::Compression::Detail {
         throw System::ObjectDisposedException(typeName, "Cannot access a closed Stream.");
     }
 
+    // Ticket #2152. Both messages are SR.CannotReadFromDeflateStream / SR.CannotWriteToDeflateStream
+    // transcribed from System.IO.Compression/src/Resources/Strings.resx:122,125. They name "the
+    // compression stream" rather than a concrete type, so all three wrappers share one string --
+    // which is what .NET does too, since GZipStream and ZLibStream delegate here.
+    void ThrowCannotReadFromCompressionStream() {
+        throw System::InvalidOperationException("Reading from the compression stream is not supported.");
+    }
+
+    void ThrowCannotWriteToCompressionStream() {
+        throw System::InvalidOperationException("Writing to the compression stream is not supported.");
+    }
+
     intcs ResolveZLibStrategy(ZLibCompressionStrategy strategy) {
         switch (strategy) {
             case ZLibCompressionStrategy::Default:           return Z_DEFAULT_STRATEGY;

modules/io-compression/src/System/IO/Compression/CompressionArgumentValidation.cpp

@@ -146,6 +146,11 @@ SharpRuntime::intcs DeflateStream::Read(SharpRuntime::bytecs* buffer,
     // Ticket #2148: a closed stream used to answer 0 here, indistinguishable from "the compressed
     // stream is exhausted". The buffer arguments are validated FIRST, matching .NET, whose
     // Read(byte[],int,int) runs ValidateBufferArguments before ReadCore's EnsureNotDisposed.
+    // Ticket #2152: .NET runs EnsureDecompressionMode BEFORE EnsureNotDisposed
+    // (DeflateStream.cs:305-308), so a disposed Compress-mode stream reports the MODE
+    // error rather than ObjectDisposedException. This used to return 0 -- a silent wrong
+    // answer a caller cannot tell from end-of-stream.
+    Detail::EnsureDecompressionMode(mode_);
     Detail::ThrowIfStreamClosed(state_ && state_->initialized, "DeflateStream");
     if (state_->finished || count == 0) return 0;
 
@@ -186,6 +191,11 @@ void DeflateStream::Write(const SharpRuntime::bytecs* buffer,
     if (count < 0) throw System::ArgumentOutOfRangeException("count", "Non-negative number required.");
     // Ticket #2148: this is the door the finding names. A write to a closed stream used to return
     // silently, so the caller's bytes vanished with no diagnostic at all.
+    // Ticket #2152, the mirror of Read's guard and in the same position
+    // (DeflateStream.cs:569). This used to reach deflate() and surface zlib's
+    // Z_STREAM_ERROR as IOException("DeflateStream: deflate error -2"), naming an
+    // internal error code for what is a caller mistake.
+    Detail::EnsureCompressionMode(mode_);
     Detail::ThrowIfStreamClosed(state_ && state_->initialized, "DeflateStream");
     if (count == 0) return;
 

modules/io-compression/src/System/IO/Compression/DeflateStream.cpp

@@ -137,6 +137,11 @@ SharpRuntime::intcs GZipStream::Read(SharpRuntime::bytecs* buffer,
     if (count < 0) throw System::ArgumentOutOfRangeException("count", "Non-negative number required.");
     // Ticket #2148: a closed stream used to answer 0 here, indistinguishable from "the
     // compressed stream is exhausted". Buffer arguments are validated first, as .NET does.
+    // Ticket #2152: .NET runs EnsureDecompressionMode BEFORE EnsureNotDisposed
+    // (DeflateStream.cs:305-308), so a disposed Compress-mode stream reports the MODE
+    // error rather than ObjectDisposedException. This used to return 0 -- a silent wrong
+    // answer a caller cannot tell from end-of-stream.
+    Detail::EnsureDecompressionMode(mode_);
     Detail::ThrowIfStreamClosed(state_ && state_->initialized, "GZipStream");
     if (state_->finished || count == 0) return 0;
 
@@ -177,6 +182,11 @@ void GZipStream::Write(const SharpRuntime::bytecs* buffer,
     if (count < 0) throw System::ArgumentOutOfRangeException("count", "Non-negative number required.");
     // Ticket #2148: this is the door the finding names. A write to a closed stream used to
     // return silently, so the caller's bytes vanished with no diagnostic at all.
+    // Ticket #2152, the mirror of Read's guard and in the same position
+    // (DeflateStream.cs:569). This used to reach deflate() and surface zlib's
+    // Z_STREAM_ERROR as IOException("GZipStream: deflate error -2"), naming an
+    // internal error code for what is a caller mistake.
+    Detail::EnsureCompressionMode(mode_);
     Detail::ThrowIfStreamClosed(state_ && state_->initialized, "GZipStream");
     if (count == 0) return;
 

modules/io-compression/src/System/IO/Compression/GZipStream.cpp

@@ -136,6 +136,11 @@ SharpRuntime::intcs ZLibStream::Read(SharpRuntime::bytecs* buffer,
     if (count < 0) throw System::ArgumentOutOfRangeException("count", "Non-negative number required.");
     // Ticket #2148: a closed stream used to answer 0 here, indistinguishable from "the
     // compressed stream is exhausted". Buffer arguments are validated first, as .NET does.
+    // Ticket #2152: .NET runs EnsureDecompressionMode BEFORE EnsureNotDisposed
+    // (DeflateStream.cs:305-308), so a disposed Compress-mode stream reports the MODE
+    // error rather than ObjectDisposedException. This used to return 0 -- a silent wrong
+    // answer a caller cannot tell from end-of-stream.
+    Detail::EnsureDecompressionMode(mode_);
     Detail::ThrowIfStreamClosed(state_ && state_->initialized, "ZLibStream");
     if (state_->finished || count == 0) return 0;
 
@@ -176,6 +181,11 @@ void ZLibStream::Write(const SharpRuntime::bytecs* buffer,
     if (count < 0) throw System::ArgumentOutOfRangeException("count", "Non-negative number required.");
     // Ticket #2148: this is the door the finding names. A write to a closed stream used to
     // return silently, so the caller's bytes vanished with no diagnostic at all.
+    // Ticket #2152, the mirror of Read's guard and in the same position
+    // (DeflateStream.cs:569). This used to reach deflate() and surface zlib's
+    // Z_STREAM_ERROR as IOException("ZLibStream: deflate error -2"), naming an
+    // internal error code for what is a caller mistake.
+    Detail::EnsureCompressionMode(mode_);
     Detail::ThrowIfStreamClosed(state_ && state_->initialized, "ZLibStream");
     if (count == 0) return;