Merci!

Daniel

On 2015-01-28 7:01 AM, Even Rouault wrote:
Daniel,


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 :
https://github.com/rouault/gdal2/commit/40eb13bb9e2a4c86df9d3cf4d030ab14d67749d5


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
mitab_tabseamless.cpp.


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.
https://github.com/rouault/gdal2/commit/a922228eff8d0b07918db520de142154e8454f6a



--
Daniel Morissette
T: +1 418-696-5056 #201
http://www.mapgears.com/
Provider of Professional MapServer Support since 2000
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Reply via email to