On 10-09-2010 18:50, Even Rouault wrote:
Frank,
yes I definitely think that 64bit integer field/FID support is a must-have for
OGR.
Here are my remarks on the proposal :
0) Minor point : about "Note that the old interfaces using "long" are already
64bit on 64bit operating systems so there is little harm to applications
continuing to use these interfaces on 64bit operating systems". This is true
on almost all platforms, except on Win64 where a long is still 32 bit...
Hi,
About the issue of the 64-bits ints on Windows we had quite some
troubles in GMT while implementing it.
The problem, as far as I remember and I'm the one who suffered more with
it (other developers use Macs only), was that one cannot read as %ld a
variable that is a 64 bits int. There was no compiling or running error,
but memory was corrupted at totally unexpected/unrelated places.
We have a note in one of our headers that describe it, and the solution
we adopted
/* Note: Under Windows 64-bit a 64-bit integer is __int64 and when used
* with scanf the format must be %lld. This is not exactly what we call
* POSIX-clean where %ld is expected. Thus, in places where such 64-bit
* variables are processed we let the compiler build the actual format
* using the GMT_LL string which is either "l" or "ll"
*/
#ifdef _WIN64
typedef __int64 GMT_LONG; /* A signed 8-byte integer under 64-bit
Windows */
#define GMT_LL "ll"
#else
typedef long GMT_LONG; /* A signed 4 (or 8-byte for 64-bit)
integer */
#define GMT_LL "l"
#endif
than we use it for example like
sscanf (p, "%" GMT_LL "d-%" GMT_LL "d", &start, &stop);
Excuse if this trivia for you guys (it wasn't for us)
Joaquim Luis
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
