man 2 open describes O_LARGEFILE as follows: O_LARGEFILE: On 32-bit systems that support the Large Files System, allow files whose sizes cannot be represented in 31 bits to be opened. I'm slightly puzzled about why you would need to specify
why would it not just go ahead and open the file anyway? My best guess is that you are promising that all indexes into the file will be 64 bit (unsigned?) ints and not a 32 bit unsigned int. In other words, it's a backward compatability feature with a little typechecking
On Fri, May 09, 2003 at 02:43:58PM +0100, Alastair Reid wrote: this flag. That is, thrown in.
SuSv3 doesn't specify a difference between RW and RO. My first guess is unexpected nontermination could occur if something loops until getting some kind of sign it's passed EOF since offsets would wrap so they wanted to avoid that compatibility issue.
Anyway, will the following kernel update help clarify things? I'll send it in to akpm et al if so. I've checked with a couple of people and it appears the code is what was intended, not the comment.
A man page update might be nice too. I checked 'man open' on Linux and it says nothing about EFBIG, although it does mention O_LARGEFILE. Cheers, Simon
At some point in the past, I wrote:
SuSv3 doesn't specify a difference between RW and RO. My first guess is unexpected nontermination could occur if something loops until getting some kind of sign it's passed EOF since offsets would wrap so they wanted to avoid that compatibility issue. Anyway, will the following kernel update help clarify things? I'll send it in to akpm et al if so. I've checked with a couple of people and it appears the code is what was intended, not the comment.
On Fri, May 09, 2003 at 03:45:23PM +0100, Simon Marlow wrote:
A man page update might be nice too. I checked 'man open' on Linux and it says nothing about EFBIG, although it does mention O_LARGEFILE.
Okay, I'll try to figure out who to pester for that; EFBIG should be listed with EEXIST et al under ERRORS. -- wli
William Lee Irwin III
On Fri, May 09, 2003 at 03:45:23PM +0100, Simon Marlow wrote:
A man page update might be nice too. I checked 'man open' on Linux and it says nothing about EFBIG, although it does mention O_LARGEFILE.
Okay, I'll try to figure out who to pester for that; EFBIG should be listed with EEXIST et al under ERRORS.
I did not find O_LARGEFILE in my man pages (Debian Woody, libc6 v2.2.5). However, I found the following under Feature Test Macros in the libc info documentation: - Macro: _FILE_OFFSET_BITS This macro determines which file system interface shall be used, one replacing the other. Whereas `_LARGEFILE64_SOURCE' makes the 64 bit interface available as an additional interface, `_FILE_OFFSET_BITS' allows the 64 bit interface to replace the old interface. Just for your information. Feri.
Ferenc Wagner writes:
- Macro: _FILE_OFFSET_BITS
Shouldn't Autoconf determine what needs to be done for large-file support? If you call the AC_SYS_LARGEFILE macro in the configure script, your build will be transparently switched to large-file support by providing the necessary compiler flags (like -D_FILE_OFFSET_BITS=64). The configure.in script coming with GHC 5.04.3 doesn't seem to make use of this. Maybe adding the macro call is all that is to fixing this problem? Peter
participants (4)
-
Ferenc Wagner -
Peter Simons -
Simon Marlow -
William Lee Irwin III