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
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
