[zlib] Only write padding bytes for DEBUG builds

In chunk_copy decompression optimization, we perform wide loads/stores within
the internal zstream buffer.

The SIMD optimization assumes that it can perform wide stores, sometimes
overwriting data on the output pointer (but never overflowing the buffer's
end as it has enough room for the write), while keeping track of the
length of decompressed stream.

To help fix buggy client code, the rest of the buffer is filled with
a defined character (since that will make faulty client code to fail
soon and fail fast).

It is save to say after all these years that Chromium code is well
behaved and works fine with the optimization, therefore we can enable
this only for DEBUG builds.

Change requested by Volker Simonis.

Bug: 1302606
Change-Id: I5ee9e7178fbbff40bf1e4f409fc528ad65597dde
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3518085
Reviewed-by: Noel Gordon <noel@chromium.org>
Commit-Queue: Adenilson Cavalcanti <cavalcantii@chromium.org>
Reviewed-by: Chris Blume <cblume@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1030214}
NOKEYCHECK=True
GitOrigin-RevId: 36be3c7a465f00f4edefccc10bba00bbebe1843d
diff --git a/contrib/optimizations/inflate.c b/contrib/optimizations/inflate.c
index e746dfa..9e4c086 100644
--- a/contrib/optimizations/inflate.c
+++ b/contrib/optimizations/inflate.c
@@ -1287,16 +1287,29 @@
        Note: a memory error from inflate() is non-recoverable.
      */
   inf_leave:
-   /* We write a defined value in the unused space to help mark
+#if defined(ZLIB_DEBUG)
+   /* XXX(cavalcantii): I put this in place back in 2017 to help debug faulty
+    * client code relying on undefined behavior when chunk_copy first landed.
+    *
+    * It is save to say after all these years that Chromium code is well
+    * behaved and works fine with the optimization, therefore we can enable
+    * this only for DEBUG builds.
+    *
+    * We write a defined value in the unused space to help mark
     * where the stream has ended. We don't use zeros as that can
     * mislead clients relying on undefined behavior (i.e. assuming
     * that the data is over when the buffer has a zero/null value).
+    *
+    * The basic idea is that if client code is not relying on the zlib context
+    * to inform the amount of decompressed data, but instead reads the output
+    * buffer until a zero/null is found, it will fail faster and harder
+    * when the remaining of the buffer is marked with a symbol (e.g. 0x55).
     */
    if (left >= CHUNKCOPY_CHUNK_SIZE)
       memset(put, 0x55, CHUNKCOPY_CHUNK_SIZE);
    else
       memset(put, 0x55, left);
-
+#endif
     RESTORE();
     if (state->wsize || (out != strm->avail_out && state->mode < BAD &&
             (state->mode < CHECK || flush != Z_FINISH)))