[GRASS5] shift bug in r.in.ascii/r.out.ascii

[Glynn Clements]

Markus Neteler wrote:

> > > Looks to me as if fseek is moving one byte too far back in the buffer on
> > > line 142 in r.in.ascii/cmd/gethead.c, putting the last digit of the number
> > > of columns as the first cell value read. Since it is followed by a
> > > newline, it is treated as value. 
> > >       fseek(fd, -(len+1), SEEK_CUR);
> > > 
> > > For me,       fseek(fd, -(len), SEEK_CUR); fixes it, but I haven't tried
> > > it with other header fields or command line options.
> > 
> > Suggestion: call ftell() before G_getl() and use fseek(SEEK_SET) to
> > restore the position. Alternatively, you could use fgetpos() and
> > fsetpos(); these are more portable, but that probably isn't an issue
> > here.
> 
> Thanks for your help! I've tried Roger's suggestion and tested in a
> Transverse Mercator and a lat/long location - it seems to work.
> 
> This version is uploaded to CVS now.
> 
> Glynn, do you think your idea is to be preferred?

Yes.

Basically, restoring the position to one which was previously recorded
with ftell() or fgetpos() is more robust than trying to compute the
required offset from the current file position.

In this case, the code is assuming that the number of bytes by which
G_getl() advances the stream's position is equal to the length of the
string which G_getl() stores in the buffer.

Whilst this may happen to be the case, I can't see anything which
actually states that it is so (G_getl() doesn't appear to have an
entry in progman50.pdf).

Furthermore, the existing implementation of G_getl() suggests that it
isn't the case as G_getl() removes the trailing newline. This implies
that the original version (offset of "-(len+1)") should be correct;
maybe there is another (equal-but-opposite) off-by-one bug elsewhere?

There is another issue, which isn't applicable here but may be worth
bearing in mind generally, which is that the behaviour of fseek() on a
text (as opposed to binary) stream is undefined unless the offset is
either zero, or the value returned from a previous call to ftell() (in
the case of SEEK_SET).

-- 
Glynn Clements <glynn.clements at virgin.net>