Re: [GRASS-dev] [GRASS GIS] #2577: d.info: entire screen version frame
#2577: d.info: entire screen version frame --+ Reporter: martinl | Owner: grass-dev@… Type: defect | Status: closed Priority: normal | Milestone: 7.0.1 Component: Display |Version: svn-trunk Resolution: fixed| Keywords: d.info, d.rast.leg CPU: Unspecified | Platform: Unspecified --+ Changes (by neteler): * keywords: d.info = d.info, d.rast.leg * milestone: 7.0.0 = 7.0.1 Comment: BTW: The changes broke d.rast.leg. Fixed in trunk r65147 and relbranch70 r65148. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2577#comment:6 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Limit in g.message? was: Limit in number of variables for r.mapcalc?
Nikos Alexandris wrote: So the question is, is there a limit in g.message? Number of characters? g.message takes the message via a command-line argument, so it's limited to any system-imposed limit on the length of an individual argument or the combined length of the arguments. But more significantly, G_message() etc use an internal buffer of 2000 bytes. A message longer than that probably won't work and may well cause the g.message to crash. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Limit in g.message? was: Limit in number of variables for r.mapcalc?
On Mon, Apr 27, 2015 at 1:16 PM, Glynn Clements gl...@gclements.plus.com wrote: But more significantly, G_message() etc use an internal buffer of 2000 bytes. A message longer than that probably won't work and may well cause the g.message to crash. How about (ab)using GPATH_MAX (include/gis.h) which is 4096 chars long and using it in general/g.message/main.c as well to avoid a buffer overflow? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
