Nicklas Larsson

@cyliang368 Good to see you working on this! May I recommend using [pre-commit](https://github.com/OSGeo/grass/blob/main/doc/development/submitting/submitting.md#use-pre-commit), which will take care of formatting and other useful checks locally.

You may also turn on `-Wall -Wextra -Wpedantic -Wvla` compiler flags as well (those are checked on some of the CI runners), thus saving some CI time.

@lbartoletti Thanks for your review, your points were accurate and I have addressed them and some other I found on the way.

Not only does the parser either return `NULL` or a non-empty string, the string is also guaranteed to contain a valid integer as it already been tested with https://github.com/OSGeo/grass/blob/8a3c6b7c7627036bf52681cdcb9c9833c398d6ac/lib/gis/parser.c#L1399 There...

Good initiative! Why not automate what *can* be automated. I looked at dependabot https://github.com/OSGeo/grass/pull/2634#issuecomment-1318760838, but this seems very similar.

This alters the output from int to float, which may not be the expected/wanted outcome. Bear in mind a postscript file is being produced. Just mention this as a caution.

> > This alters the output from int to float, which may not be the expected/wanted outcome. Bear in mind a postscript file is being produced. Just mention this as...

> I can't fine specs for PostScript BITMAP to see if these numbers can be floats. Conversion to int would preserve the current behavior. There is the [PostScript Language Reference](https://www.adobe.com/jp/print/postscript/pdfs/PLRM.pdf)....

> So I gave it locally a try: > > ``` > # run on entire GRASS-core tree > cppcheck --std=c++17 --enable=warning,style,performance,portability --inconclusive -j 4 --error-exitcode=1 -q -Iinclude/ . >...

Looking into a couple of random issues from the list, they seem to be real issues.