[GRASS-dev] g.list type=rast gives floating point exception

Using 2006-10-18 cvs, I get a floating point exception when running g.list
type=rast, with no output produced. Strangely, g.list -f rast gives me a
full verbose listing of all rasters in my mapset. g.list type=vect and
g.list type=region also work fine.

Any ideas what's going on?

~ Eric.

Patton, Eric wrote:

Using 2006-10-18 cvs, I get a floating point exception when running g.list
type=rast, with no output produced. Strangely, g.list -f rast gives me a
full verbose listing of all rasters in my mapset. g.list type=vect and
g.list type=region also work fine.

Any ideas what's going on?

"g.list -f" invokes the $GISBASE/etc/lister/<type> program to list the
maps; without -f, the G_list_element() function is used.

If there exists a map whose name is 80 characters or longer,
G_list_element() will end up dividing by zero[1], which will normally
result in a floating-point exception.

[1] It computes the number of columns as:

      num_cols = 80 / (maxlen + 1); /* + 1: column separator */

where maxlen is the length of the longest map name in the list. If the
denominator is greater than 80, num_cols will be zero. num_cols is
used as the RHS of the % (modulus) operator, hence the division by
zero. I'll add a test for that case.

--
Glynn Clements <glynn@gclements.plus.com>

Glynn Clements wrote:

where maxlen is the length of the longest map name in the list. If the
denominator is greater than 80, num_cols will be zero. num_cols is
used as the RHS of the % (modulus) operator, hence the division by
zero. I'll add a test for that case.

Glynn,

In current CVS the floating point exception with long names is gone,
but if any of the elements listed by g.list is longer than my terminal
width, all the elements are separated with a redundant empty line.

To notice that create eg. a vector of a name this long:

bricz_pkt_shorties_break_onlycat_prune_poly_prune_addcat_tmp_12724_0_v_breach5_9_2

and do 'g.list vect'. You'll see what I mean. Could those sparse empty
lines be avoided?

Maciek

Maciej Sieczka wrote:

> where maxlen is the length of the longest map name in the list. If the
> denominator is greater than 80, num_cols will be zero. num_cols is
> used as the RHS of the % (modulus) operator, hence the division by
> zero. I'll add a test for that case.

Glynn,

In current CVS the floating point exception with long names is gone,
but if any of the elements listed by g.list is longer than my terminal
width, all the elements are separated with a redundant empty line.

To notice that create eg. a vector of a name this long:

bricz_pkt_shorties_break_onlycat_prune_poly_prune_addcat_tmp_12724_0_v_breach5_9_2

and do 'g.list vect'. You'll see what I mean. Could those sparse empty
lines be avoided?

I've committed the attached patch, which avoids padding the last
column. This prevents the blank lines which occur when padding beyond
the width of the terminal.

--
Glynn Clements <glynn@gclements.plus.com>

(attachments)

G_list_element.diff (671 Bytes)