> Date: Fri, 14 Nov 2008 21:01:39 +0100 > From: [EMAIL PROTECTED] > > > The function pdf_fsys_disk_get_free_space() returns a `pdf_size_t' > > representing number of *bytes*. Our `pdf_size_t' is just a typedef > of > > `size_t', which is usually a typedef of `unsigned int' which is > usually > > 32bits in 32-bit machines (not sure of its size in 64-bit machines). > > > > Anyway, if size of pdf_size_t is 32bits, the maximum number of bytes > > which a pdf_size_t is able to handle is 4GBytes, which of course is > not > > enough: > > (((2^32)/1024)/1024)/1024 = 4 > > > > Basically, the pdf_fsys_disk_get_free_space() function should return > a > > pdf_i64_t instead of a pdf_size_t. > > > > Also, the main API of the Filesystem module > (pdf_fsys_get_free_space()) > > should be modified. > > > > Maybe would be a good idea to use a pdf_off_t (defined in pdf-types) > > for all the filesystem-related sizes. What do you think? > > > > Yes, it's probably better than using directly pdf_i64_t. In OS without > built-in 64bit support, pdf_off_t will be 32-bits, and 64-bits or longer > in all the others. Right? > > Right. The pdf_off_t type will always be the indicated one to refer to > file offsets.
Hey guys. Dumb question, but, would that data type allow us to represent say, 10 GBytes ? We're talking about disk space, so it could be 4 Terabytes too !! If that's not the case then we need a more complex structure for sizes not just a variable. regards, -gerel
