[GRASS-dev] Re: About the vector changes

[Markus Metz]

Glynn:
> Breaking backwards compatibility is allowed in 7.0. We'll probably be
> breaking raster compatibility at some point (but in a far more
> fundamental way; old rasters won't be recognised at all).
>
> Something this fundamental should have been announced (maybe it was
> and I missed it). Also, the error message is misleading.
>   
I will announce it more loudly next time :-)
The error message should be fixed, see other post.
> Markus:
>> My argument is that 
>> enabling backwards compatibility would be about the same effort like 
>> rebuilding topology. I could write a module that converts any existing 
>> sidx file to the new format or builds the spatial index from topo if no 
>> sidx file is found, then writes a new sidx file in the new format. That 
>> would avoid rebuilding the core topology and category index.
>>     
>
> Maybe the sidx file should have been renamed?
>   
That would be fool-proof and no problem.
>   
>>> PERMANENT/vector/fields contains:
>>>
>>> 	-rw-r--r-- 1 root root  4117 May 25  2004 cidx
>>> 	-rw-r--r-- 1 root root 27905 May 25  2004 coor
>>> 	-rw-r--r-- 1 root root    55 May 25  2004 dbln
>>> 	-rw-r--r-- 1 root root   278 May 25  2004 head
>>> 	-rw-r--r-- 1 root root   186 May 25  2004 hist
>>> 	-rw-r--r-- 1 root root 24538 May 25  2004 sidx
>>>       
>> There is no sidx file for vectors in
>> http://grass.osgeo.org/sampledata/spearfish_grass60data-0.3.tar.gz
>>     
>
> IOW: sidx was removed in 6.0 (existing sidx files were silently
> ignored), then an entirely different sidx file was added recently, and
> the code is confused by the existence of a 5.7 sidx file, right?
>   
Yes. I wasn't aware that 5.7 was writing sidx files. I found the 
spearfsh57 sample dataset just now, will use it for more testing in the 
future.
>   
>>> Also, this needs to be checked for anything which uses VECT_CFLAGS,
>>> which isn't limited to v.* modules (a few g.* and r.* modules use
>>> vector functions).
>>>       
>> I fixed r.drain, v.in.dxf, v.vol.rst. AFAICT all other g.*, r.* and v.* 
>> modules are ok. Please let me know if I missed something.
>>     
>
> I don't know which modules need fixing and which don't. I was just
> pointing out that e.g. g.{copy,remove,rename,list} use the vector
> libraries (but don't use VECT_CFLAGS; is that a bug?)
Yes. Anything that uses vector libraries must use the same LFS-related 
flags like the vector libs, otherwise there can be segfaults because the 
size of a number of structures, most importantly struct Map_info, is on 
32bit systems dependent on the LFS flags.
> , r.to.vect,
> d.vect, etc use the libraries and VECT_CFLAGS, so it isn't just v.*
> modules which need to be checked. It might just be v.* modules which
> need to be fixed; I don't know.
>   
OK. I will check all modules including <grass/vector.h> or any of the 
headers in include/vect. All vector modules should be fixed by now. Of 
the raster modules, only r.drain needed fixing, all other were ok. But I 
will check again.
>   
>> I got carried away (replacing all fseek/ftell occurrences I could find 
>> with G_fseek/G_ftell, adjusting off_t as you showed above) and also made 
>> r3.in|out.v5d LFS-safe, but did not submit. Should I?
>>     
>
> Yes; 
Will do, testing highly welcome!
> ideally, we should use G_{fseek,ftell} everywhere. Ultimately, it
> would be better to enable -D_FILE_OFFSET_BITS=64 globally (to ensure
> that there aren't any cases where a FILE* is obtained via fopen64()
> then passed to code which can't handle it), which means making
> everything LFS-aware.
>   

That's beyond my scope because aclocal.m4 and configure.in need 
adjustment, and I won't touch these. I guess you are suitably qualified 
for the task ;-)

Markus M