Ask in a comment whether we should test HAVE_STRUCT_STAT_ST_BLKSIZE.

We're defining it now based on whether there's an st_blksize member of
struct stat.  We're currently testing _STATBUF_ST_BLKSIZE, but that's
not guaranteed to be defined on platforms that have an st_blksize member
of struct stat (it's not defined on macOS, for example).

Change-Id: I4e6011a7668da94cf1ca6328e29c50924dd1d8b0
Reviewed-on: https://code.wireshark.org/review/32381
Reviewed-by: Guy Harris <guy@alum.mit.edu>

1 files changed, 19 insertions, 1 deletions

diff --git a/wiretap/file_wrappers.c b/wiretap/file_wrappers.c
index 4788dccfb7..acb7a4a177 100644
--- a/wiretap/file_wrappers.c
+++ b/wiretap/file_wrappers.c
@@ -854,7 +854,25 @@ gz_reset(FILE_T state)
 FILE_T
 file_fdopen(int fd)
 {
-#ifdef _STATBUF_ST_BLKSIZE      /* XXX, _STATBUF_ST_BLKSIZE portable? */
+    /*
+     * XXX - we now check whether we have st_blksize in struct stat;
+     * it's not available on all platforms.
+     *
+     * I'm not sure why we're testing _STATBUF_ST_BLKSIZE; it's not
+     * set on all platforms that have st_blksize in struct stat.
+     * (Not all platforms have st_blksize in struct stat.)
+     *
+     * Is there some reason *not* to make the buffer size the maximum
+     * of GBUFSIZE and st_blksize?  On most UN*Xes, the standard I/O
+     * library does I/O with st_blksize as the buffer size; on others,
+     * and on Windows, it's a 4K buffer size.  If st_blksize is bigger
+     * than GBUFSIZE (which is currently 4KB), that's probably a
+     * hint that reading in st_blksize chunks is considered a good
+     * idea (e.g., an 8K/1K Berkeley fast file system with st_blksize
+     * being 8K, or APFS, where st_blksize is big on at least some
+     * versions of macOS).
+     */
+#ifdef _STATBUF_ST_BLKSIZE
     ws_statb64 st;
 #endif
     int want = GZBUFSIZE;