[GRASS-dev] Re: About the vector changes
Markus Metz
markus.metz.giswork at googlemail.com
Mon Aug 10 03:01:05 EDT 2009
Glynn:
> [...] 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".
>
OK. But on Linux 32 without LFS I get
port_init.c:217: warning: overflow in implicit constant conversion
at compile time because long long int is available but sizeof(off_t) =
4. Portability and its test is ok because OFF_T_TEST is not used in this
case.
To avoid this warning I could use in port_init()
#ifdef HAVE_LONG_LONG_INT
#ifdef HAVE_LARGEFILES
u_o = OFF_T_TEST;
#else
u_o = LONG_TEST;
#endif
#else
u_o = LONG_TEST;
#endif
but I am not sure if HAVE_LARGEFILES is always set on 64bit systems also
without --enable-largefile.
>
> 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"?
On level 0, it is always an int. It's the ID of the rectangle passed to
int RTreeInsertRect(struct Rect *r, int tid, struct RTree *t)
as tid. That applies to all three cases above.
I am writing out the rectangle ID as off_t although it is int and have
to read it as off_t then cast it to int again when loading the sidx file
to memory for updating. Of course I could also write the ID as int and
read it as int, then there would be no type casting, at the cost of one
more if ... else ... .
> If so,
> why is it stored in the file as an off_t?
>
On higher levels (RTree internal nodes), it is the position in file of
the child nodes of a node. For large sidx files, off_t is needed. The
corresponding line in spindex_rw.c is
668 s[top].pos[s[top].branch_id - 1] = nextfreepos;
where I set the node positions in file as off_t.
This is related to the use of union Child: on level 0, int id is used,
on higher levels, struct Node *ptr is used.
Markus M
More information about the grass-dev
mailing list