[gdal-dev] Call for discusson on RFC 31 - OGR 64bit Integer Fields and FIDs

[Daniel Morissette]

Hi Even,

Replies in-line below

On 2015-01-27 12:47 PM, Even Rouault wrote:
>
> Not sure if you saw my answer to Dmitriy as it ended up into a separate thread
> due to dumb email agent. Reposting it inline
>

No, I'm sorry it seems that I had missed it.


> """Dmitriy,
>
> The main reason for the new symbol is that if we change the return type it
> might cause crashing problems that are not detected at compile time if GetFID
> is used in a printf like function. For example
>
> printf("%ld %s", GetFID (), str)
>
> Even
> """
>

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.

>>
>> 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.
>
> OK thanks for the hint, I'll have a look at this. Do you have samples datasets
> that would trigger that issue ?
>

No. I don't think I've ever seen or heard of a seamless table large 
enough to trigger the issue.


-- 
Daniel Morissette
T: +1 418-696-5056 #201
http://www.mapgears.com/
Provider of Professional MapServer Support since 2000