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

[Helena]

Has anybody tested whether r.in.arc and r.out.arc does not have the same problem ?
At least one version of r.out.arc was written based on r.out.ascii so the bug might
have
been transfered there too.

Helena


Glynn Clements wrote:

> 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>
> _______________________________________________
> grass5 mailing list
> grass5 at geog.uni-hannover.de
> http://www.geog.uni-hannover.de/mailman/listinfo/grass5