[GRASS5] shift bug in r.in.ascii/r.out.ascii
hmitaso at unity.ncsu.edu
Thu Jul 5 18:39:48 EDT 2001
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
been transfered there too.
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?
> 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
More information about the grass-dev