pdf-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pdf-devel] pdf_fsys_disk_get_free_space()


From: gerel
Subject: Re: [pdf-devel] pdf_fsys_disk_get_free_space()
Date: Fri, 14 Nov 2008 15:44:03 -0800 (PST)

 > Date: Fri, 14 Nov 2008 21:01:39 +0100
 > From: address@hidden
 > 
 >    >    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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]