[GRASS5] [bug #977] (grass) s.in.ascii core dumps

[Glynn Clements]

Request Tracker wrote:

> Subject: s.in.ascii core dumps

> s.in.ascii sites=eaurinia input=e_aurinia.txt fs=","
> or 
> s.in.ascii sites=eaurinia input=e_aurinia.txt fs=,
> dumps core on data in the form like this:
> 3500900,5704300,"AAAAAAAANF","Name",
> 3500900,5704300,"AAAAAAAANF","Name, another Name",
> 3555700,5697800,"AAAAAAAANG","Name with umlauts äöü",
> 3501500,5694000,"AAAAAAAANH","Name...",19760101
> 
> cat e_aurinia.txt | tr "," "\t"| s.in.ascii sites=eaurinia2
> works partially. Only some lines are imported. If i cut off all fields
> exept the easting/northing part it works.
> 
> I am in a hurry, so i am not able to check further. 
> 
> I think that s.in.ascii should at least not core dump on input,
> irrespectively how weird it is.
> 
> My guess is that the problem is either the unquoted "," inside the
> qouted field or the empty fifth field.

AFAICT, it's actually a bug in G_parser() regarding the "fs=," option;
the split_opts() function attempts to split the "answer" field into
multiple answers, regardless of whether the "multiple" field is set. 
Furthermore, zero-length options result in a NULL answer rather than
the empty string. This causes G_recreate_command() to segfault, as it
expects opt->answers[0] to be valid.

If I fix split_opts(), so that opt->answers[0] is just set to
opt->answer when opt->multiple is false, s.in.ascii works OK.

BTW, s.out.ascii only outputs the first three sites, so there's
something wrong there ($LOCATION/site_lists/eaurinia is correct).

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