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

List:       kfm-devel
Subject:    Re: Inconsistency in filesize variable types
From:       Martijn Klingens <martijn () martijn ! homeip ! net>
Date:       2001-12-10 9:11:43
[Download RAW message or body]

On Sun, 9 Dec 2001, Waldo Bastian wrote:
> Most of it but I haven't changed the signals yet. I'm a bit reluctant to that
> since there is no compile-time type checking for signal connections :-(
>
> I was wondering to have both 'long' and 'long long' version but I'm not sure
> if we can do that. I'm afraid that will lead to problems on platforms where
> both long and long long are the same size.

Not only that, but it will in the end also trigger obscure bugs if code
uses the 'low-precision' version of the signal and starts using it for KIO
operations on large files eventually. I think we have to live with it and
change the signals ASAP, so we have a decent amount of time to test and
fix the inevitable bugs before 3.0 is out.

I don't think we'll exhaust the 64bit address space anytime soon, but
people also said that of 32bit and 16bit in the past and got proven wrong
as well, so it might be better to introduce a 'KIO_size_t' type or so as
typedef that could scale source-compatible to KDE 6.0 with 256bit
filesystem support. Although 64bit is an awful lot of information to
fill...

(Even if we don't do that I still think 'uint64' is more compatible than
'long long', but that's another story. Or does connect() only work on the
'real' datatype and not on a typedef?)

Martijn


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