[gdal-dev] Call for discusson on RFC 31 - OGR 64bit Integer Fields and FIDs
dmorissette at mapgears.com
Wed Jan 28 07:11:55 PST 2015
On 2015-01-28 7:01 AM, Even Rouault wrote:
>> This may not be true on all platforms, but at least with GCC, we get
>> warnings in a case like this, e.g.
>> #include <stdio.h>
>> #include <stdint.h>
>> int main()
>> int64_t id=10;
>> printf ("%d %s\n", id, "test");
>> return 0;
>> $ gcc -Wall ttt.c -o ttt
>> ttt.c: In function 'main':
>> ttt.c:8: warning: format '%ld' expects type 'long int', but argument 2
>> has type 'int64_t'
>>> I've taken that approach from Frank's initial draft and that seamed a
>>> valid concern. That said, if you guys think that changing the return
>>> type is better, I've no strong mind.
>> I don't feel that strongly about it. I was mostly wondering if there
>> would be a way to avoid the *64() suffixes.
> Yes GCC nicely warns. I don't think MSVC does, but oh well people building on
> Windows are used to self-inflicted pain ;-)
> So I've renamed GetFID64() -> GetFID() and GetFeatureCount64() -> GetFeature()
> in latest commit :
>>>> Also note that in the list of driver upgrades, you could add potential
>>>> enhancement to the support for MITAB "TAB Seamless Tables" which had a
>>>> potential FID overflow problem on very large tables with 32 bit ids. The
>>>> driver would have caught and reported an error in this case, but that
>>>> limitation can be solved with 64 bit ids if/when the code is upgraded to
>>>> use them. Look for TABSeamless::EncodeFeatureId() and related methods in
> I've made changes in TABSeamless and now builds a 64 bit FID with the upper
> 32bits being for the index table and the lower 32bits for the feature within
> the table.
> Looking at the code, I've manually forged a simple seamless table and added it
> in autotest.
T: +1 418-696-5056 #201
Provider of Professional MapServer Support since 2000
More information about the gdal-dev