[GRASS-dev] [GRASS GIS] #2986: r.mapcalc with same variable on LHS and RHS

[GRASS GIS]

#2986: r.mapcalc with same variable on LHS and RHS
--------------------------+-------------------------
  Reporter:  mankoff      |      Owner:  grass-dev@…
      Type:  defect       |     Status:  closed
  Priority:  major        |  Milestone:  7.0.4
 Component:  Docs         |    Version:  7.0.3
Resolution:  fixed        |   Keywords:  r.mapcalc
       CPU:  Unspecified  |   Platform:  Unspecified
--------------------------+-------------------------

Comment (by wenzeslaus):

 Replying to [comment:11 glynn]:
 > I'm not sure that the behaviour would even be desirable.

 Although, in GRASS or GIS in general, we usually create new data under new
 names, from general programming perspective `a = a + 1` makes sense. The
 following, which is an equivalent of `a = a + 1`, actually works:

 {{{
 r.neighbors in=test1 out=test1 size=25 --o
 }}}

 I'm not sure if it is actually legal. We should make it clear. Is it
 module dependent? What about `G_check_input_output_name()`?

 Doing this with vectors gives an error (''Output vector map <firestations>
 is used as input''):

 {{{
 v.extract in=test2 cats=10,11,12,13 output=test2 --o
 }}}

 I assume this applies to all vector modules (and that
 `Vect_check_input_output_name()` should be used to ensure it).

 > If change is warranted, it would be better to just check for the
 situation where an output map will overwrite any of the input maps, and
 report it as an error.

 Warning for start and perhaps an (fatal) error in the future are
 appropriate. We should either support it or forbid it. (I don't know how
 people interpret "the behavior is undefined" - it is common in C/C++
 programming, but I'm not so sure about GIS).

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2986#comment:15>
GRASS GIS <https://grass.osgeo.org>