[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Fwd: Re: 64 bit file support
From:       Martijn Klingens <mklingens () yahoo ! com>
Date:       2001-08-11 13:11:42
[Download RAW message or body]

On Saturday 11 August 2001 01:26, Waldo Bastian wrote:
> On Friday 10 August 2001 06:59 pm, shaheed wrote:
> > Please don't use "long long" - Digital UNIX, Solaris 8, Irix 6.5.recent
> > and possibly others use "long" to mean 64 bits with the default ABI, but
> > this lack of precision is just not helpful. I suspect that off_t will
> > work provided we check that sizeof(off_t) == sizeof(off64_t). If not, I
> > prefer the KIO::filesize_t (unsigned?) or perhaps KIO::offset_t (signed?)
> > concept.
>
> The problem is that we can't include config.h in our API header files.
> Maybe we can work around that by installing a different header file
> depending on some configure test and map KIO::filesize_t to a 64 bit
> integer if we can find one (either long or long long) and to a 32 bit
> integer (long) if we can't.

Maybe a _very_ ignorant question, but what's wrong with creating a uint64 
datatype (if that isn't already defined somewhere - I believe Qt defines a 
type that does exactly this) for file sizes and using it _everywhere_, 
including systems with 32bit filesystems? It shouldn't be that hard to check 
if the high bits are set in the cpp implementation files and this has the 
advantage that the code is litterally the same from an app's point of view. 
We essentially hide the implementation details behind the API.

Again, there might be reasons for not doing this, but as I fail to see them I 
ask here...

Martijn

[prev in list] [next in list] [prev in thread] [next in thread]