Author Topic: Open large files on 32-bit OS and ANSI C  (Read 1369 times)

0 Members and 1 Guest are viewing this topic.

Offline KarelTopic starter

  • Super Contributor
  • ***
  • Posts: 2198
  • Country: 00
Open large files on 32-bit OS and ANSI C
« on: August 27, 2023, 12:22:35 pm »
Using ANSI C, is there already a way to read/write large files (> 2.1 4.2GB) on a 32-bit OS?
« Last Edit: August 27, 2023, 12:29:20 pm by Karel »
 

Offline ledtester

  • Super Contributor
  • ***
  • Posts: 3032
  • Country: us
Re: Open large files on 32-bit OS and ANSI C
« Reply #1 on: August 27, 2023, 01:45:40 pm »
It will depend on the OS.

For Linux/Unix I found this:

Portable support for large files
https://stackoverflow.com/a/30867832

which points to calls such as fseeko(), ftello(), fseeko64(), ftello64() and lseek64().

For WinXP SP2 you have the Set/GetFilePointerEx() pair of calls.
 

Offline KarelTopic starter

  • Super Contributor
  • ***
  • Posts: 2198
  • Country: 00
Re: Open large files on 32-bit OS and ANSI C
« Reply #2 on: August 27, 2023, 02:44:05 pm »
It will depend on the OS.

For Linux/Unix I found this:

Portable support for large files
https://stackoverflow.com/a/30867832

which points to calls such as fseeko(), ftello(), fseeko64(), ftello64() and lseek64().

For WinXP SP2 you have the Set/GetFilePointerEx() pair of calls.

It's not  ANSI C
 

Online ejeffrey

  • Super Contributor
  • ***
  • Posts: 3598
  • Country: us
Re: Open large files on 32-bit OS and ANSI C
« Reply #3 on: August 27, 2023, 03:13:37 pm »
Yes.  You can fopen() a file of any size and read it continuously until EOF.

What you can't do is fseek() in a single step. Although technically you can call fseek(fh, LONG_MAX, SEEK_CUR) in a loop to advance to an arbitrary position.

 

Offline KarelTopic starter

  • Super Contributor
  • ***
  • Posts: 2198
  • Country: 00
Re: Open large files on 32-bit OS and ANSI C
« Reply #4 on: August 27, 2023, 03:35:31 pm »
Yes.  You can fopen() a file of any size and read it continuously until EOF.

What you can't do is fseek() in a single step. Although technically you can call fseek(fh, LONG_MAX, SEEK_CUR) in a loop to advance to an arbitrary position.

Interesting. But the limitation of fseek(0 and ftell() seems cumbersome.

It's weird that ANSI C has never been updated with 64-bit variants (that work on 32-bit hosts).

 

Offline TheCalligrapher

  • Regular Contributor
  • *
  • Posts: 151
  • Country: us
Re: Open large files on 32-bit OS and ANSI C
« Reply #5 on: August 27, 2023, 04:10:18 pm »
Using ANSI C, is there already a way to read/write large files (> 2.1 4.2GB) on a 32-bit OS?

The question, as stated, makes no sense. There's no connection of any kind between bitness of OS and ANSI C. ANSI C does not dictate any limitation on the file size, tied to either the bitness of OS or anything else.

The answer depends purely on implementation. If an implementation decides to support reading terabyte-sized files under a 8-bit OS - it can do so (under assumption that such files actually exist). It will require some extra effort, but there's nothing difficult about it. Or it can decide not to support such files.

Note that the oft-mentioned problem with file positioning functions (e.g. `ftell`/`fseek`) and large files already exists even in 64-bit-specific environments. Due to poor design of C standard library, these functions expose naked `long` as the type that specifies absolute file position. This is a signed type, meaning that 64-bit-wide `long` is already insufficient to cover all possible absolute positions and sizes available in unsigned 64-bit-wide range. In other words, in an environment with even narrower `long` the problem is more pronounced in purely quantitative terms, but it is not really new.
« Last Edit: August 27, 2023, 04:28:36 pm by TheCalligrapher »
 

Online ejeffrey

  • Super Contributor
  • ***
  • Posts: 3598
  • Country: us
Re: Open large files on 32-bit OS and ANSI C
« Reply #6 on: August 27, 2023, 05:33:57 pm »
Interesting. But the limitation of fseek(0 and ftell() seems cumbersome.

It's weird that ANSI C has never been updated with 64-bit variants (that work on 32-bit hosts).

It's not that weird.  Stdio is really geared towards streaming linearly through a file which has always worked fine with any size file. Likewise you can easily append to a file regardless of size.  Consider most of the standard unix file utils for which the C standard library was originally designed: most of them never seek at all or possibly only to the end of the file.  Also remember that for text files fseek with a non zero offset isn't even guaranteed to work at all.

In my experience people doing random access to binary files they tend to use lower level IO calls such as read() / write() or mmap() anyway.  They don't need or want the buffering support of stdio and there is little advantage to it. Those are OS dependent and come in 64 bit versions whenever the OS supports it.

 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 5953
  • Country: fi
    • My home page and email address
Re: Open large files on 32-bit OS and ANSI C
« Reply #7 on: August 29, 2023, 08:04:45 am »
In my experience people doing random access to binary files they tend to use lower level IO calls such as read() / write() or mmap() anyway.  They don't need or want the buffering support of stdio and there is little advantage to it. Those are OS dependent and come in 64 bit versions whenever the OS supports it.
Correct.  I showed a mmap() approach for a terabyte-sized file back in 2011 at linuxquestions.org, but it does require a 64-bit POSIX-y (Linux, BSD, etc.) OS.

Using ANSI C, is there already a way to read/write large files (> 2.1 4.2GB) on a 32-bit OS?
Sure.  There is a standard, POSIX.1 aka IEEE Std 1003., for low-level OS interfaces in C, including I/O.  It is mostly compatible with the C standard, but overrides or redefines certain details.

You can find the Single UNIX Specification at opengroup.org for free, whose Base specification is technically identical to POSIX.1; specifically, IEEE Std. 1003-2017 Base specification is identical to POSIX.1-2017, and is the most recent and current version as of 2023.

The relevant interfaces here are open()/openat() for opening file-like things using file descriptors, close() for closing open file descriptors (and sockets), pread() for reading binary data from a specific offset without affecting the current file position, pwrite() for writing binary data starting at a specific offset without affecting the current file position, among other things.

The type used for file descriptors is int; the type for amounts of bytes to be read/written is size_t; the type returned by read/write operations is ssize_t; and the type describing a file position is off_t.  For their exact definitions, see the POSIX.1/SUSv Base specification Headers section; specifically <sys/types.h> for a summary, and <stdlib.h> and <unistd.h> for where they are defined (and which you need to include to have these types available).

Per POSIX.1, size_t is a type large enough to describe the size of anything in memory.  It is the type the sizeof operator evaluates to, for example.  ssize_t is a type that can represent the size of anything in memory, and -1 (for error indication).

The type relevant for this thread, off_t, can be either 32-bit or 64-bit in several 32-bit architectures, including x86.

For the GNU C Standard Library aka glibc, the preprocessor macro _FILE_OFFSET_BITS can be used to set the size (by defining it to value 64 before including any headers) on 32-bit systems to select 64-bit "large file" support.  Note that Linux is not perfectly POSIX in all details, so comparing the POSIX definitions to Linux and other systems' implementations using e.g. Linux man pages online is often useful.

On OpenBSD and FreeBSD, off_t has been 64-bit for at least 15 years –– probably longer; it was 64-bit in 2008 –– even on 32-bit architectures.

For newlib, the commonly used embedded standard C library on 32-bit microcontrollers and embedded processors, the default interface is assumed to be 32-bit, and if the 64-bit variants are supported they have different names (basically with 64 suffix) and use _off64_t for the file position instead of _off_t.

For example, an ANSI C program expanded from
Code: [Select]
#define _FILE_OFFSET_BITS 64
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <errno.h>

int main(int argc, char *argv[])
{
    return 0;
}
that uses open(), close(), read()/pread() and/or write()/pwrite(), optionally lseek(), and so on, will have a 64-bit off_t type on Linux, Mac OS, OpenBSD, FreeBSD, and several other operating systems, and is fully able to manipulate files over 4 GiB in size.

Note that you should never rely on lseek() to obtain the file size.  Use fstat() instead; but only if you cannot simply read everything until end of input (read() or pread() returning zero).  The only fully portable and reliable way is to simply read until there is no more data to be read, as lseek() will fail if the file is appended to during reading, and neither lseek() nor fstat() work on pipes, sockets, character devices, or pseudofiles (like /proc and /sys pseudofile hierarchies in Linux that export OS/kernel information).
 

Offline KarelTopic starter

  • Super Contributor
  • ***
  • Posts: 2198
  • Country: 00
Re: Open large files on 32-bit OS and ANSI C
« Reply #8 on: August 29, 2023, 08:05:08 am »
Due to poor design of C standard library, these functions expose naked `long` as the type that specifies absolute file position. This is a signed type, meaning that 64-bit-wide `long` is already insufficient to cover all possible absolute positions and sizes available in unsigned 64-bit-wide range. In other words, in an environment with even narrower `long` the problem is more pronounced in purely quantitative terms, but it is not really new.

That poor design is dictated and/or left open to the implementation by ANSI C (ISO/IEC 9899:2011 (E)), for example:

int fseek(FILE *stream, long int offset, int whence);

where a long int usually has a size of 32 bits on 32-bit systems and 64 bits on 64-bit systems
(ofcourse windows is the exception where it's usually 32 bits on both 32 and 64-bit versions of windows,
because it's microsoft, they do everything different than the rest of the world).

and

int fsetpos(FILE *stream, const fpos_t *pos);

where fpos_t is defined by ANSI C as:

"a complete object type other than an array type capable of recording all the
information needed to specify uniquely every position within a file."


My point is, and probably I'm a bit naive here, I thought that ANSI C was created so that the same code can run correctly
after being compiled whit whatever ANSI C compatible compiler.

So, why did ANSI not add new functions like e.g. fseek64() and fsetpos64()?
That would remove some burden when writing portable software that can also open large files on 32-bit systems.




 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 5953
  • Country: fi
    • My home page and email address
Re: Open large files on 32-bit OS and ANSI C
« Reply #9 on: August 29, 2023, 08:22:40 am »
So, why did ANSI not add new functions like e.g. fseek64() and fsetpos64()?
Because that, and other related stuff, moved (eventually) to POSIX.1 aka IEEE Std. 1003.1.

Do remember that C standardization efforts moved from ANSI to ISO in the 1989.  ANSI started the standardization work in 1983 (X3J11 committee), and finalized it in 1989 as ANSI X3.159-1989.  The effort then moved to ISO, which ratified the same ANSI X3.159-1989 standard as ISO/IEC 9899:1990.  Those two are referred to as C89 (and C90, respectively).

The first IEEE Std. 1003.1 (POSIX.1) was ratified in 1988.  It was always about OS level (and initially UNIX and UNIX-like interoperable systems), so it made sense for ISO and IEEE C-related efforts to split into system-agnostic (ISO C) and system/OS-internal (POSIX.1) approaches.

I and others could describe some of the history related to these standardization efforts (including ANSI escape codes, a subset of which are still commonly used to add color to and control text-based terminals, and were originally supported even in MS-DOS using ansi.sys, but whose support Microsoft dropped at some point from Windows' default terminal application), and indeed Microsoft has been the biggest antagonist with its historical Embrace-Extend-Extinguish (or Embrace-Extend-make-incompatible-profit!) approach.  But, while historically accurate, it would sound a lot like ranting againt Microsoft, which actually has shifted its attitudes quite a bit in the last decade or so; however, you still cannot fully rely on any standards when using C on Windows.  For example, for no reason in particular, getting wide output or UTF-8 character set to work in the default console (command-line) still requires nonstandard extensions to be used.
 
The following users thanked this post: Karel, DiTBho

Offline DiTBho

  • Super Contributor
  • ***
  • Posts: 3714
  • Country: gb
Re: Open large files on 32-bit OS and ANSI C
« Reply #10 on: August 29, 2023, 10:11:05 am »
edit: OT

why did ANSI not add new functions like e.g. fseek64() and fsetpos64()?
That would remove some burden when writing portable software that can also open large files on 32-bit systems.

I wrote a custom b*tree-based filesystem for XINU/Kernel, and that's exactly the approach I used:
- my own lib-c library
- my own lib-fs library with 32 and 64 bit versions of all the filesystem primitives!
- practically { lib-fs , lib-fs32 , lib-fs64 }

on GNU/Linux 32bit ... I have to use "magic" #defines, #include files in the right order and after the "magic" #define to be correctly #ifdef activated, and "magic" flags to have 64bit filesystem support (ext2,ext3,ext4,xfs do support it, fat16 and old minix-fs-v1 do not) on a 32bit userland.


that's life ...  :-//
« Last Edit: August 29, 2023, 03:14:11 pm by DiTBho »
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 

Offline DiTBho

  • Super Contributor
  • ***
  • Posts: 3714
  • Country: gb
Re: Open large files on 32-bit OS and ANSI C
« Reply #11 on: August 29, 2023, 10:28:43 am »
edit: OT

or, do you prefer this approach?

Code: [Select]
void foo
(
     string_t file_name,
     file_mode_t file_mode
)
{
     fs_t fs;

     ...
     fs'bit=64; /* please, use 64bit filesystem primitives */
     fs.open(file_name, file_mode);
     ...
}
(my-c code)

fs_t is an object and can overload all the filesystem methods { open, seek, pos, read, write, close, ... } according to the defined "bit" property.

experimental personal-compiler project, I haven't taken an official position yet, in some ways I like it, in others I don't  :-// :-//
« Last Edit: August 29, 2023, 03:14:31 pm by DiTBho »
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 5953
  • Country: fi
    • My home page and email address
Re: Open large files on 32-bit OS and ANSI C
« Reply #12 on: August 29, 2023, 10:58:55 am »
(my-c code)
Be careful, there is "ANSI C" in the thread title, and OP already stated they're specifically interested in ANSI C solutions only!



I should probably also note that POSIX.1 is all about interoperability between systems.  The OS-level C interfaces are just one part of it; it also specifies a large set of command-line tools and a POSIX shell language derived from Bourne shells.

The Base definitions define what POSIX.1 requires of the implementation (OS, C compiler, and so on).  Basically, any implementation and its C compiler and standard C library can be POSIX.1 compatible, but an ANSI or ISO C standard implementation is not necessarily POSIX.1 compatible.  POSIX.1 is much stricter, and defines things the C standards leave implementation defined, or do not touch at all.

The System Interfaces define the C language OS or system interfaces.

The Shell and Utilities, Shell Command Language defines the POSIX shell command language.  Bash does have a POSIX shell compatibility mode, but Debian Almquist SHell aka dash is used when a faster (lower startup latency, smaller memory footprint) POSIX shell interpreter is needed; dash is included in BusyBox, and used in many embedded Linux targets like OpenWRT.

The Rationale is informative, but its Portability Considerations section is very useful for anyone intending to write portable code.

To simplify a bit: if we exclude Windows (but include WSL and WSL2, basically), POSIX.1 provides the standard for interoperability under fully-featured operating systems, regardless of the native word size.  In fact, it would be perfectly possible to implement 64-bit file I/O POSIX.1 support even on an 8-bit or 16-bit processor.  This is also the reason why many embedded targets use a freestanding C environment –– i.e., NO standard C library available at all, as specified in the ISO C standard(s) –– but a lot of POSIX.1'isms, especially in the types and how they are used.  In particular, the way that logical types like file offset are given their own types whose properties are separately specified, instead of just hardcoding them as char, short, int, or long, the basic integer types defined by ANSI C.  (It's not out of fanboyism to POSIX.1, but because POSIX.1 evolved over a couple of decades to be the way people can do interoperable C, surviving the competition among many different approaches; i.e. known working approaches.  It's not perfect by any means, but it is the best we have right now.)
 

Offline KarelTopic starter

  • Super Contributor
  • ***
  • Posts: 2198
  • Country: 00
Re: Open large files on 32-bit OS and ANSI C
« Reply #13 on: August 29, 2023, 11:35:28 am »
Long story short, if I want to write portable code that allows me to open large files also on 32-bit systems,
I have to declare something like this:

Code: [Select]
#if defined(__APPLE__) || defined(__MACH__) || defined(__APPLE_CC__) || defined(__HAIKU__) || defined(__ANDROID__)

#define fopeno fopen

#else

#define fseeko fseeko64
#define ftello ftello64
#define fopeno fopen64

#endif

#ifdef _WIN32

#ifndef __MINGW32__
/* needed for visual c */
#undef fseeko
#define fseeko _fseeki64

#undef ftello
#define ftello _ftelli64

#undef fopeno
#define fopeno fopen

#endif

#endif

Using this I can use fopeno(), fseeko() and ftello() on most common OS'es and with most common compilers, right?

 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 5953
  • Country: fi
    • My home page and email address
Re: Open large files on 32-bit OS and ANSI C
« Reply #14 on: August 29, 2023, 11:56:33 am »
Using this I can use fopeno(), fseeko() and ftello() on most common OS'es and with most common compilers, right?
Won't work in glibc-based systems (many/most Linux ones) without modifications.

It'd make more sense to create a header file, say posix-io.h that includes the necessary headers on target systems (using pre-defined compiler macros), exposing fopen(), fclose(), errno and strerror(), ftello(), fseeko(), fgetc(), feof() (for examining the "already encountered end of input" flag, not testing whether file position is at the end of input), fread(), fwrite(), getline() and getdelim(), and the always 64-bit off_t type.  For Windows, MSVCRT does not implement getline() or getdelim(), so one must provide fgets()/fgetc()/fscanf()-based compatible implementations (which perform acceptably well).

Note that such an interface would be compatible with POSIX.1-2001 and later.

Optionally it could also implement utility functions like int get_file_size(FILE *, off_t *) (returning 0 if success and off_t saved, otherwise -1 with errno set) and int ftype(FILE *) (returning an int enum, for example 0 = unknown, 1 = regular file, 2 = pipe or socket or device (cannot obtain length, etc., with -1 indicating an error and errno set).
« Last Edit: August 29, 2023, 12:02:53 pm by Nominal Animal »
 

Offline KarelTopic starter

  • Super Contributor
  • ***
  • Posts: 2198
  • Country: 00
Re: Open large files on 32-bit OS and ANSI C
« Reply #15 on: August 29, 2023, 12:24:45 pm »
Using this I can use fopeno(), fseeko() and ftello() on most common OS'es and with most common compilers, right?
Won't work in glibc-based systems (many/most Linux ones) without modifications.

I tried and it seems to work fine on both Linux and windows with different compilers.
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 5953
  • Country: fi
    • My home page and email address
Re: Open large files on 32-bit OS and ANSI C
« Reply #16 on: August 29, 2023, 12:29:46 pm »
Using this I can use fopeno(), fseeko() and ftello() on most common OS'es and with most common compilers, right?
Won't work in glibc-based systems (many/most Linux ones) without modifications.
I tried and it seems to work fine on both Linux and windows with different compilers.
Enable compiler warnings, then.  Or you didn't show all the #defines and #includes you used.
 

Offline KarelTopic starter

  • Super Contributor
  • ***
  • Posts: 2198
  • Country: 00
Re: Open large files on 32-bit OS and ANSI C
« Reply #17 on: August 29, 2023, 01:00:58 pm »
Using this I can use fopeno(), fseeko() and ftello() on most common OS'es and with most common compilers, right?
Won't work in glibc-based systems (many/most Linux ones) without modifications.
I tried and it seems to work fine on both Linux and windows with different compilers.
Enable compiler warnings, then.  Or you didn't show all the #defines and #includes you used.

Code: [Select]
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>

In the makefile:

Code: [Select]
CC = gcc
CFLAGS = -O2 -Wall -Wextra -Wshadow -Wformat-nonliteral -Wformat-security -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE
LDLIBS = -lm

Sorry, I forgot to mention the compiler options  :-[
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 5953
  • Country: fi
    • My home page and email address
Re: Open large files on 32-bit OS and ANSI C
« Reply #18 on: August 29, 2023, 01:55:16 pm »
Okay – although I'd add -D_FILE_OFFSET_BITS=64 too as _LARGEFILE_SOURCE is obsolete for glibc –, but I still think you'd be better off using the POSIX.1 subset, using the same preprocessor logic.  Something along the lines of
Code: [Select]
#ifndef   POSIX_IO_H
#define   POSIX_IO_H

// Define USE_CUSTOM_GETLINE to use custom getline() implementation
#undef  NEED_CUSTOM_GETLINE

// Define USE_CUSTOM_GETDELIM to use custom getdelim() implementation
#undef  NEED_CUSTOM_GETDELIM

// Operating systems:
#if defined(_WIN32)
#if defined(__MINGW32__)
// 32-bit MingW on Windows

// TODO

#elif defined(__MINGW64__)
// 64-bit MingW on Windows

// TODO

#elif defined(_WIN64)
// 64-bit Windows

// TODO

#else
// 32-bit Windows

// TODO

#endif
// Microsoft Visual C Runtime does not implement getline(), getdelim()
#define  NEED_CUSTOM_GETLINE
#define  NEED_CUSTOM_GETDELIM

#elif defined(__APPLE__) && defined(__MACH__)
// Mac OS

// At least Darwin 10.5 and later use 64-bit off_t by default
#ifndef _POSIX_C_SOURCE
#define _POSIX_C_SOURCE 200809L
#endif
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>

#elif defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__) || defined(__bsdi__) || defined(__DragonFly__)
// BSD variants

// Always 64-bit off_t, with fseeko() and ftello() defined in sys/types.h
#include <stdlib.h>
#include <sys/types.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>

#elif defined(__HAIKU__)
// Haiku

// POSIX.1 compatible by default, and Haiku and BeOS off_t was always 64-bit.
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>

#elif defined(__linux__)
// Linux and Android

// Legacy definitions
#ifndef _LARGEFILE_SOURCE
#define _LARGEFILE_SOURCE
#endif
#ifndef _LARGEILE64_SOURCE
#define _LARGEFILE64_SOURCE
#endif

// Ensure 64-bit off_t
#undef _FILE_OFFSET_BITS
#define _FILE_OFFSET_BITS 64

// Include POSIX.1 C interfaces
#ifndef _POSIX_C_SOURCE
#define _POSIX_C_SOURCE 200809L
#endif

#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>

#endif /* Operating systems */

#if defined(NEED_CUSTOM_GETLINE) || defined(USE_CUSTOM_GETLINE)

// Custom getline() implementation
static ssize_t custom_getline(char **lineptr, size_t *size, FILE *stream)
{
   // ...
}
#undef  getline
#define  getline  custom_getline
#endif

#if defined(NEED_CUSTOM_GETDELIM) || defined(USE_CUSTOM_GETDELIM)

// Custom getdelim() implementation
static ssize_t custom_getdelim(char **lineptr, size_t *size, int delim, FILE *stream)
{
    if (delim == '\n')
        return custom_getline(lineptr, size, stream);

   // ...
}
#undef  getdelim
#define  getdelim  custom_getdelim
#endif

#endif /* POSIX_IO_H */
but the above is untested.

This way, your source code only needs to start with #include "posix-io.h", and use the POSIX.1 interfaces (ftello(), fseeko(), and otherwise standard C99 or later <stdio.h>, <string.h>, and <errno.h> stuff), and you can omit the -D command-line options.  This then also works with clang, too, as well as other C compilers (including Intel Compiler Collection), and possibly even MS C++ in C "mode".
« Last Edit: August 29, 2023, 01:59:39 pm by Nominal Animal »
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4189
  • Country: us
Re: Open large files on 32-bit OS and ANSI C
« Reply #19 on: August 29, 2023, 06:35:16 pm »
Quote
if I want to write portable code that allows me to open large files also on 32-bit systems,


Are you sure that your "32bit system" OPERATING SYSTEM and DISK FORMAT support "large files"?
For instance, FAT32 is limited to 4GB-1, and HFS apparently 2GB.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf