grass
grass copied to clipboard
lib/psdriver: Fix issues with wrong type of arguments to printf
Each call to the printf function or a related function should include the type and sequence of arguments defined by the format. If the function is passed arguments of a different type or in a different sequence then the arguments are reinterpreted to fit the type and sequence expected, resulting in unpredictable behavior.
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 a caution.
I can change it to do an explicit cast to an int, the issue is just with an implicit cast between types. I wasn't 100% sure what was appropriate, but it's an easy fix to make.
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.
I can change it to do an explicit cast to an int, the issue is just with an implicit cast between types. I wasn't 100% sure what was appropriate, but it's an easy fix to make.
I'm not saying this is wrong, only that it changes the output. Looking at the other psdriver functions, formatting of double is made with%f. I haven't found a way to trigger this code to test the difference...
I can't fine specs for PostScript BITMAP to see if these numbers can be floats. Conversion to int would preserve the current behavior.
I have tried in the last weeks too to find the specs, of at least BOX and BITMAP, but didn't find the info I was looking for.
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. (A couple of weeks ago I was able to download from there, now not...).
PostScript is a script language and BITMAP is a procedure defined in:
https://github.com/OSGeo/grass/blob/f13a4924e15d28117a6780a77df9a0eeac46238e/lib/psdriver/psdriver.ps#L50-L56
This is used later in: https://github.com/OSGeo/grass/blob/f13a4924e15d28117a6780a77df9a0eeac46238e/lib/psdriver/draw_bitmap.c#L7
I believe, the cur_x, cur_y, ncols, nrows variables are saved in stack with gsave. They represent drawing coordinates. Other ps code use floats (%f) for x and y, so that is probably ok here too.
The problem I have was to trigger this code, it is likely only implemented as needed for comply to the driver interface:
https://github.com/OSGeo/grass/blob/f13a4924e15d28117a6780a77df9a0eeac46238e/lib/driver/driver.h#L44
Knowing who is behind this driver, the code is likely broadly correct, working, but never put up to the test.