Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lib/psdriver: Fix issues with wrong type of arguments to printf #3551

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

kpolchow
Copy link
Contributor

@kpolchow kpolchow commented Apr 2, 2024

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.

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.
@kpolchow kpolchow marked this pull request as draft April 2, 2024 01:18
@github-actions github-actions bot added C Related code is in C libraries labels Apr 2, 2024
@neteler neteler changed the title Fix issues with wrong type of arguments to printf lib/psdriver: Fix issues with wrong type of arguments to printf Apr 2, 2024
@kpolchow kpolchow marked this pull request as ready for review April 3, 2024 01:48
@nilason
Copy link
Contributor

nilason commented Apr 7, 2024

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.

@kpolchow
Copy link
Contributor Author

kpolchow commented Apr 8, 2024

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.

@nilason nilason added this to the 8.4.0 milestone Apr 9, 2024
@nilason nilason self-assigned this Apr 9, 2024
@nilason
Copy link
Contributor

nilason commented Apr 9, 2024

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...

@wenzeslaus
Copy link
Member

I can't fine specs for PostScript BITMAP to see if these numbers can be floats. Conversion to int would preserve the current behavior.

@wenzeslaus wenzeslaus modified the milestones: 8.4.0, Future Apr 27, 2024
@echoix
Copy link
Member

echoix commented Apr 27, 2024

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.

@nilason
Copy link
Contributor

nilason commented Apr 27, 2024

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:

/BITMAP {
gsave
4 2 roll translate
1 index 7 add 8 idiv string /tmpstr exch def
true [1 0 0 1 0 0] {currentfile tmpstr readhexstring pop} imagemask
grestore
} bind def

This is used later in:

output("%d %d %d %d BITMAP\n", cur_x, cur_y, ncols, nrows);

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:

void (*Bitmap)(int, int, int, const unsigned char *);

Knowing who is behind this driver, the code is likely broadly correct, working, but never put up to the test.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C Related code is in C libraries
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants