Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!network.ucsd.edu!usc!wupost!waikato.ac.nz!comp.vuw.ac.nz!mark Newsgroups: comp.unix.bsd Subject: Re: New filesystem for BSD4.4 Message-ID: <20m80k$e5t@st-james.comp.vuw.ac.nz> From: mark@comp.vuw.ac.nz (Mark Davies) Date: 28 Jun 1993 07:52:52 GMT References: <C9BCvB.C3s@candle.uucp> Organization: Dept. of Comp. Sci., Victoria Uni. of Wellington, New Zealand. NNTP-Posting-Host: bats.comp.vuw.ac.nz Lines: 26 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. badly :-). 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. When porting code to 4.4 the first thing I do is grep for occurances of the above and then verify that the correct prototypes for these functions are being picked up prior to these occurances and that there is a prototype for any function that an st_size is passed to (or explicitly cast it to the appropriate type). 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. cheers mark