[GRASS5] [bug #4244] (grass) segmentation library short read()s

[Hamish]

> Request Tracker wrote:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=4244
> ----------------------------------------------------------------
> 
> Subject: segmentation library short read()s
...

> >Specifically, the line:
> >
> >    if ( lseek(fd,nbytes-1,SEEK_SET) < 0 ) { 
> >
> >should use SEEK_CUR rather than SEEK_SET, as it is supposed to be
> >writing nbytes from the current position, not from the start of the
> >file.
> >
> >Note that there is a 20-byte header (5 "int"s) at the start of the
> >file, which would explain why the read() is always 20 bytes short
> >(zero_fill() is always called just after the header has been
> >written).
> >
> >I'm not sure why that header is there in the first place; segment
> >files aren't supposed to be shared across different processes, are
> >they?
>
> The patch is quite correct; the segment file was shorter of 20 bytes
> when using the lseek zero_fill.
> The header is required because the segment_format just create the
> file, while the segment_init initialize it.
> The typical segment library usage was:
>     fd=open_for_writing
>     segment_format(fd,..)
>     close(fd)
>     fd=open_for_reading_writing
>     segment_init(fd,...)
>  
> and the parameters are shared through the header.
> The lseek zero_fill  does not really allocate the file, it just 
> extend the file size, so it's  possible  a write error  later, but
> it's a lot faster than writing zero bytes to a file. The write error
> are handled inside segment_pageout and segment_put_row with a
> G_warning and a -1 return code.



.... so, should this change be committed to CVS or not?

> >    if ( lseek(fd,nbytes-1,SEEK_SET) < 0 ) { 
> >
> >should use SEEK_CUR rather than SEEK_SET

If not, I find it worring that r.cost output is not the same from GRASS
6.0 to GRASS 6.1.


thanks,
Hamish