Don't rely on zlib's gzgetc() macro.

tglsfdc · tglsfdc · commit 33276cd0272e · 2025-10-19T14:36:58.000-04:00
It emerges that zlib's configuration logic is not robust enough to guarantee that the macro will have the same ideas about struct field layout as the library itself does, leading to corruption of zlib's state struct followed by unintelligible failure messages. This hazard has existed for a long time, but we'd not noticed for several reasons: (1) We only use gzgetc() when trying to read a manually-compressed TOC file within a directory-format dump, which is a rarely-used scenario that we weren't even testing before 20ec995. (2) No corruption actually occurs unless sizeof(long) is different from sizeof(off_t) and the platform is big-endian. (3) Some platforms have already fixed the configuration instability, at least sufficiently for their environments. Despite (3), it seems foolish to assume that the problem isn't going to be present in some environments for a long time to come. Hence, avoid relying on this macro. We can just #undef it and fall back on the underlying function of the same name. Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/2122679.1760846783@sss.pgh.pa.us Backpatch-through: 13
diff --git a/src/bin/pg_dump/pg_backup_archiver.h b/src/bin/pg_dump/pg_backup_archiver.h
@@ -38,6 +38,16 @@
  */
 #ifdef HAVE_LIBZ
 #include <zlib.h>
+
+/*
+ * We don't use the gzgetc() macro, because zlib's configuration logic is not
+ * robust enough to guarantee that the macro will have the same ideas about
+ * struct field layout as the library itself does; see for example
+ * https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=59711
+ * Instead, #undef the macro and fall back to the underlying function.
+ */
+#undef gzgetc
+
 #define GZCLOSE(fh) gzclose(fh)
 #define GZWRITE(p, s, n, fh) gzwrite(fh, p, (n) * (s))
 #define GZREAD(p, s, n, fh) gzread(fh, p, (n) * (s))
