From cc08075f66cd84949524444321bb59566f22dce0 Mon Sep 17 00:00:00 2001 From: Andy Polyakov Date: Wed, 27 Jun 2018 11:57:45 +0200 Subject: [PATCH] crypto/o_fopen.c: alias fopen to fopen64. Originally fopen(3) was called from bio/bss_file.c, which performed the aliasing. Then fopen(3) was moved to o_fopen.c, while "magic" definition was left behind. It's still useful on 32-bit platforms, so pull it to o_fopen.c. Reviewed-by: Paul Dale Reviewed-by: Tim Hudson (Merged from https://github.com/openssl/openssl/pull/6596) (cherry picked from commit 2369111fd94ebc9b7d37e68f3ea9629f2fe5fa2e) --- crypto/o_fopen.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/crypto/o_fopen.c b/crypto/o_fopen.c index a3a006574d..63a31b0e1b 100644 --- a/crypto/o_fopen.c +++ b/crypto/o_fopen.c @@ -7,6 +7,24 @@ * https://www.openssl.org/source/license.html */ +# if defined(__linux) || defined(__sun) || defined(__hpux) +/* + * Following definition aliases fopen to fopen64 on above mentioned + * platforms. This makes it possible to open and sequentially access files + * larger than 2GB from 32-bit application. It does not allow to traverse + * them beyond 2GB with fseek/ftell, but on the other hand *no* 32-bit + * platform permits that, not with fseek/ftell. Not to mention that breaking + * 2GB limit for seeking would require surgery to *our* API. But sequential + * access suffices for practical cases when you can run into large files, + * such as fingerprinting, so we can let API alone. For reference, the list + * of 32-bit platforms which allow for sequential access of large files + * without extra "magic" comprise *BSD, Darwin, IRIX... + */ +# ifndef _FILE_OFFSET_BITS +# define _FILE_OFFSET_BITS 64 +# endif +# endif + #include "internal/cryptlib.h" #if !defined(OPENSSL_NO_STDIO) -- 2.25.1