[GRASS5] GRASS 5.3 new bug in s.in.ascii (+source code updated)

[Hamish]

> > I have hit a bug in GRASS 5.3--the first I've run into in a couple 
> > months of pretty solid work with this version.
> > 
> > When trying to import a simple text file into the sites format, I
> > get an error if the file contains non-numeric strings. Here is the
> > file I was trying to import
> > 
> > 501175.0877193,3836254.44444444,1968,room
> > 502782.10526316,3839709.53216374,1915,room
> > 502621.40350877,3842789.64912281,1889,room
> > 503183.85964912,3844798.42105263,1874,room
> > 501175.0877193,3842602.16374269,1894,roomblock
> > 506505.02923977,3837566.84210526,1941,roomblock
> > 
> > s.in.ascii sites=clearcreek_sites input=clearcreek_sites.txt fs=,


I can import that file without any problem.
GRASS53: > s.in.ascii in=barton_test.txt sites=barton_test fs=,

result:
name|barton_test
desc|s.in.ascii sites=barton_test input=barton_test.txt fs=
501175.0877193|3836254.44444444|#1 %1968 @room
502782.10526316|3839709.53216374|#2 %1915 @room
502621.40350877|3842789.64912281|#3 %1889 @room
503183.85964912|3844798.42105263|#4 %1874 @room
501175.0877193|3842602.16374269|#5 %1894 @roomblock
506505.02923977|3837566.84210526|#6 %1941 @roomblock


[Note you can just create ascii files with the correct format and put
them in the $MAPSET/site_lists/ directory as a last resort..]


I see the "desc|... fs=" has lost its "," .. need to fix that.


> > It doesn't matter whether or not I put quotes around the character 
> > strings. The error I get is:
> > 
> > *** malloc[14292]: error for object 0x357b: Pointer being
> > reallocated was not allocated
> > ERROR: G_realloc: out of memory
> > 
> > If I get rid of the string fields (i.e., 'room' and 'roomblock'), it
> > imports just fine.

Can you make this fail with a clean & up to date install of GRASS
5.0, 5.3, and 5.7? All have different versions now (as of today).


> > I'd SWEAR this was working just fine in a previous version of 
> > s.in.ascii I was using last November. I didn't notice anything had
> > been changed in the CVS for s.in.ascii in the past few months so I
> > don't understand why this WAS working but isn't now.

Can you reproduce it on another computer? Is it only on 5.7?


> One possibility is changes to src/libes/gis/sites.c.

The 5.0/5.3 version hasn't been touched in 22 months.
The 5.7 version had a change to a memory call 2 months ago.. -> !!??
  see grass51/lib/sites/sites.c  G_sites_close()


> Another possibility is that the bug has always been present, but you
> haven't been bitten by it before; bugs relating to malloc()ed memory
> are often like that.


Upon doing some updates to s.in.ascii yesterday (see below) I came
across something, but didn't figure it out fully. It's a bit of a grey
area but I think it fails in a bad way (assigning data to sites which
don't have any). It isn't seen with uniform data coverage, which is the
usual case.


Take this input file:
2649375 6503980
2682513 5996973 5
2473745 5735185
2308057 5483339 text
2155623 5413749
2496942 6036738 2 word
2609610 6235565
2649375 6503980 two text
2682513 5996973 
2473745 5735185 2.34 5.67
2308057 5483339 
2155623 5413749

s.in.ascii produces:

name|test
desc|s.in.ascii sites=test fs=space
2649375|6503980|#1
2682513|5996973|#2 %5
2473745|5735185|#3 %5
2308057|5483339|#4 %5 @text
2155623|5413749|#5 %5 @text
2496942|6036738|#6 %2 @word
2609610|6235565|#7 %2 @word
2649375|6503980|#8 %2 @two @text
2682513|5996973|#9 %2 @two @text
2473745|5735185|#10 %2.34 %5.67 @two @text
2308057|5483339|#11 %2.34 %5.67 @two @text
2155623|5413749|#12 %2.34 %5.67 @two @text