[GRASS-dev] r38992 Vect_get_num return long

[Glynn Clements]

Markus Metz wrote:

> AFAIKT, r38992 Vect_get_num return long has no effect because the number 
> of features (for each type) is stored as plus_t which is int. If you 
> want to prepare the vector libs to support more than INT_MAX objects, I 
> would suggest to use
> 
> plus_t Vect_get_num_primitives(const struct Map_info *, int);
> 
> etc and then think about what type is appropriate for plus_t.
> 
> I would suggest *not* to use long because long is the same like int on 
> 32 bit (4 bytes) and the same like long long int on 64 bit (8 bytes), 
> i.e. a vector written with 64 bit may not be readable with 32 bit which 
> is against all the efforts to keep the vector format independent of 
> platform/architecture/compiler. Some unsigned integer type should work, 
> else some checks would be needed similar to what Glynn recently 
> implemented to get an integer type of size 8 in port_init.c. E.g. use 
> long if possible else use long long if possible else fatal error, no 
> integer of size 8 available (or is there something else that could have 
> a size of 8 ?).

	#ifdef HAVE_LONG_LONG_INT
	typedef long long longest;
	#else
	typedef long longest;
	#endif

?

If you're desperate for more than 32 bits, an IEEE "double" can
represent integers between -2^53 and 2^53 exactly, but this is likely
to be more trouble than it's worth (you have to be careful with
division, you can't use a double as an array index, you can't use
shifts or bitwise operators, ...).

-- 
Glynn Clements <glynn at gclements.plus.com>