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 <gl...@gclements.plus.com> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev