l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
April 21: Google Glass
Next Installfest:
TBD
Latest News:
Mar. 18: Google Glass at LUGOD's April meeting
Page last updated:
2001 Dec 30 17:02

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Re: [vox] Large File Support
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Re: [vox] Large File Support



On Tue, 27 Mar 2001, Peter Jay Salzman wrote:

> On Tue 27 Mar 01,  1:02 PM, jdnewmil@dcn.davis.ca.us said: 
> > On Tue, 27 Mar 2001, Peter Jay Salzman wrote:
> > 
> > > regardless of whether they created new functions to fix this or not...
> > > 
> > >   is my statement not true?
> > 
> > Which one?  That they created the problem? absolutely incorrect.
>  
> jeff, here is a post to the kernel mailing list by the author of the ext2
> filesystem.  at this point, you're calling him wrong, not me.
> 
>       http://www.uwsg.iu.edu/hypermail/linux/kernel/9912.3/0042.html
> 
> here's the highlight:
> 
> 
>       o The problem lies with ISO/ANSI C's fseek()/ftell(), which use a "long"
>       for the offset.  Why fpos_t wasn't used (consistently!) is beyond me, but
>       hindsight is 20/20.  AFAIK, these are the only two functions that *must*
>       break if >2GB files are permitted with 32-bit longs.  Other functions
>       *can* break (like the present case), but aren't *required* to break by
>       the POSIX+C standards.
> 
> 
> what is your reply to theodore ts'o?

That they would have been overstepping their mandate to have changed those
prototypes.  ts'o is welcome to his opinion, but standards are built by
consensus.

My after-the fact guessing about their debate is something like this: Lots
of code uses arithmetic on the the file position.  They could have
predicted two possible outcomes to switching entirely to fpos_t: the type
would be a larger integer type, or a struct capable of encapsulating
multiple ints.  If they required fseek to use fpos_t, they would have to
require that fpos_t be defined by each implementation such that it
supported addition and subtraction... that is, it would have to be some
kind of integer type.  Since near-term solutions to the large file problem
using structs were attractive, locking out those solutions drove them to
leave fseek alone and define new functions.

> 
> it occurs to me that fsetpos and fseekpos aren't solutions, either.  simply
> because of all the code that's already out there that use fseek and ftell.

yes, that is true.  As with Intel's "segmented architecture", the "fpos as
a struct" option will probably end up as a bywater in computing history
when we all start using 64-bit processors.

> peter (who is now going on to do something useful today).

And leave us here wasting our time? argh...

---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil@dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
Work:<JeffN@endecon.com>              Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...2k
---------------------------------------------------------------------------


LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
O'Reilly and Associates
For numerous book donations.