gvmap add_point: abbreviate no-op 'MAX' call

c193a91a0e9d8565e85bd6953a2c64e971d6ab79 seems to have incorrectly assumed
multiplication has a higher precedence than casts. In reality, it is the
opposite, meaning the first parameter to this `MAX` call was always 0. So the
entire expression would evaluate to 20. Empirically this seems to have been fine
since this code has been in use for over a decade with no specific problems
blamed on this area. So lets just abbreviate it into what it evaluates to.

Gitlab: #2269

diff --git a/cmd/gvmap/make_map.c b/cmd/gvmap/make_map.c
index 4e8316556f675b5c425b34f7dc3a40cc9bcb4de8..6e9da497e277a72e5562afff1cce08f1696ebb5d 100644 (file)
--- a/cmd/gvmap/make_map.c
+++ b/cmd/gvmap/make_map.c
@@ -1297,7 +1297,7 @@ static void add_point(int *n, int igrp, double **x, int *nmax, double point[], i
 
   if (*n >= *nmax){
     int old_nmax = *nmax;
-    *nmax = MAX((int) 0.2*(*n), 20) + *n;
+    *nmax = 20 + *n;
     *x = gv_recalloc(*x, 2 * old_nmax, 2 * *nmax, sizeof(double));
     *groups = gv_recalloc(*groups, old_nmax, *nmax, sizeof(int));
   }