Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!ux1.cso.uiuc.edu!howland.reston.ans.net!agate!dog.ee.lbl.gov!horse.ee.lbl.gov!torek From: torek@horse.ee.lbl.gov (Chris Torek) Newsgroups: comp.unix.bsd Subject: Re: New filesystem for BSD4.4 Date: 8 Jul 1993 10:56:25 GMT Organization: Lawrence Berkeley Laboratory, Berkeley CA Lines: 45 Message-ID: <32202@dog.ee.lbl.gov> References: <C9BCvB.C3s@candle.uucp> <20m80k$e5t@st-james.comp.vuw.ac.nz> NNTP-Posting-Host: 128.3.112.15 >In article <C9BCvB.C3s@candle.uucp> root@candle.uucp (Bruce Momjian) writes: >>I understand the new filesystem for BSD4.4 will have 64-bit file sizes. >>I was wondering how code already written under the assumption that the >>return value from lseek() and fseek() will fit in a long(32 bits) is >>going to handle such large files. In article <20m80k$e5t@st-james.comp.vuw.ac.nz> mark@comp.vuw.ac.nz (Mark Davies) writes: >badly :-). Indeed. >in 4.4 off_t is a 64 bit quantity. This doesn't affect fseek() whose >argument is a long but it does affect lseek(), truncate() and ftruncate() >and also the st_size field in the stat structure. All quite correct. Note that fseek/ftell cannot handle large files, but fgetpos/fsetpos can. This is forced by the fact that `long' is still 32 bits and the ANSI-mandated type for the fseek/ftell position is `long'. (This particular problem can go away on machines where `long' is 64 bits.) >[verify proper prototypes and/or insert casts where needed] These are >by far the most common porting difficulties encountered building for 4.4. >This of course doesn't answer the question of whether many of these programs >would actually work correctly if presented with a file of size greater than >2^32. Indeed. GNU gdb, for instance, assumes that it can read the entire contents of a source file into memory. Of course, gcc will never compile a file larger than 2^32 bytes in the first place. :-) But this sort of thing bit me, for instance, when trying to bring up gdb (the current version of gdb was 4.4 at the time, oddly enough): it had code of the form: char *p = xmalloc(statbuf.st_size); without a prototype for xmalloc(). This wound up malloc'ing 0 bytes every time, as the code in xmalloc() was using the upper word of the 64-bit file size as if it were a simple 32-bit integer. -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov