[GRASS-dev] Re: About the vector changes

[Glynn Clements]

Markus Metz wrote:

> > However, as a result of the LFS changes, the code has some type
> > mismatches on 32-bit systems with LFS enabled.
> >
> > Most of these are due to passing off_t's to G_debug() with %ld as the
> > format (it needs to be %lld for a 64-bit off_t on a 32-bit platform;
> > we really need a macro for this). There's also one G_fatal_error()
> > call which has "%d".
> 
> There was something about long long int, it's part of the C99 standard 
> but not supported by all compilers if I remember correctly. That's the 
> reason for HAVE_LONG_LONG_INT?

Yep. We don't require a C99 compiler, so we can't use "long long int"
or %lld unconditionally. However, we can assume that they exist if LFS
is enabled.

> > In lib/vector/diglib/port_init.c,
> >
> > 	#define OFF_T_TEST 0x0102030405060708
> >
> > should have an LL suffix (it's too large for an "int"), and this
> > should ideally be conditionalised 
> 
> Its usage is conditionalised: it's only used if sizeof(off_t) == 8, 
> otherwise OFF_T_TEST is ignored and LONG_TEST is used instead. Applies 
> to port_test.c as well. The current portability test is passed on 32bit 
> with LFS.

I mean compile-time conditonalisation. An integer literal without a
trailing suffix is an "int". Using a larger type to hold the value
where necessary is a gcc extension. Other compilers may simply
truncate the value to an int, even if off_t is 64 bits.

The latest change:

	#define OFF_T_TEST 0x0102030405060708LL

will fail to compile with a compiler which doesn't have long long int.
Both the definition and use of OFF_T_TEST need to be conditionalised
with "#ifdef HAVE_LONG_LONG_INT".

> > But I would strongly suggest
> > using a union rather than casting; 
> You suggested that earlier already. First time I work with unions, done 
> in trunk r38654. Could please have a look at lib/vector/rtree/index.h? 
> The compiler warnings above about pointer <-> integer casts are gone, 
> but I'm not sure if I used that union thing correctly.

I still see:

719:	    s[top].sn.branch[j].child.id =
720:		(int)s[top].childpos[j];

754:				s[top].sn.branch[j].child.id =
755:				    (int)s[top].childpos[j];

Also:

1011:			if (!shcb((int)s[top].sn.branch[i].child, cbarg)) {

A narrowing cast always brings up the question of "what if the value
won't fit in the destination type"?

Am I missing something, or is childpos[j] *always* an "int"? If so,
why is it stored in the file as an off_t?

> Picking your brain, unrelated: can I assume that DBL_MAX is always 
> available on all platforms? I would like to use it in lib/vector/rtree.

DBL_MAX is always available in float.h.

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