From fd7ff6916ca06b6a501a9c1675020d409718aef7 Mon Sep 17 00:00:00 2001 From: Guy Harris Date: Sun, 10 Mar 2019 11:11:32 -0700 Subject: 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 --- wiretap/file_wrappers.c | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) (limited to 'wiretap') 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; -- cgit v1.2.3