GD is an open source code library for the dynamic creation of images by programmers. GD is written in C, and “wrappers” are available for Perl, PHP and other languages. GD creates PNG, JPEG and GIF images, among other formats. GD is commonly used to generate charts, graphics, thumbnails, and most anything else, on the fly. While not restricted to use on the web, the most common applications of GD involve web site development.
See the GD website for more informations.
FS#92 — imagearc/imagefilledarc DoS fix problem
Opened by Claes Månsson (cj) - Tuesday, 12 June 2007, 10:03 GMT+1
Last edited by Pierre Joye (Pierre) - Thursday, 14 June 2007, 21:25 GMT+1
|
DetailsThe DoS fix for imagearc and imagefilledarc ( http://bugs.libgd.org/?do=details&task_id=74 ) may be too pedantic when cropping angles. Consider a start angle of 270 and an end angle of 630. The intent is clearly to draw a full revolution of the arc from 12 to 12 o clock, but the modulo arithmetic converts the end angle to 270 which means that nothing is drawn. This new behaviour broke a piechart script that we were using, so the issue is not merely theoretical. A fix may go along the lines of this (untested code):
int diff;
diff = e - s;
if (diff > 360) {
diff = diff % 360;
}
if (s > 360) {
s = s % 360;
}
e = s + diff;
|
Thursday, 14 June 2007, 21:25 GMT+1
Reason for closing: Fixed
Additional comments about closing: Fixed in CVS (you can try with either GD itself or in php in the next 5.2 snapshot). I used the rules defined earlier.
Good catch, this is the second report about this issue. The other one was less obvious as the end angle was not equal to the start angle but simply larger than 360. I think your example should be fixed as it is clear a regression.
Adding this test after the sanitization process should fix (cannot test rihgt now but it should work):
... sanitized with % ... then: if (s == e) { s = 0; e = 360; }I will fix this regression before 2.0.35.
Thanks! I think there's a little problem with your fix, though. Here's a situation that can occur when you're drawing a pie chart:
Say you feed it with two values, one being a 0% slice, and another being a 100% slice. Imagearc would be fed: 0%: 270, 270 100%: 270, 630
Here, the 270, 270 really means "draw nothing", so s == e would make it do the wrong thing, since that would be interpreted as wanting to draw 360 degress.
The script should fix its logic, it seems wrong to play with these values like that :) But the regression is here and should be fixed: Let say if the input start-end:
I think that covers all cases. I will try to produce a test case for each of them later tonight. Can you try it with your script with or without the fix?
Thanks,
A digression perhaps: I'm not sure what the best behaviour would be. One thing that strikes me, is that the start/end angle way of providing drawing instructions can thought of as start angle + revolution angle instead.
They're perfectly possible to translate between, but the intent of start+revolution becomes a bit clearer, since there would be no way to misinterpret "how far" to draw the arcs. The start angle would always work using modulo 360, and here's how your examples could be done:
1. 10 + 10: arc from 10 to 20
2. 20 + 350: arc from 20 to 10 (through 0, large arc)
3. 0 + 360: full
4. 0 + 380: 0 ? 20 (overdrawn two times the last 20°? :)
5. 270 + 360: full (like 0 ? 360)
6. 270 + 0: nothing, equal before sanitization
See how the intent of case 5 and 6 becomes clearer?
I'm not saying that the calling interface should be changed, working in start+revs could be done internally.
But, I'm very new to imagearc/imagefilledarc, so I don't know how other people are using it, and what to expect from it.
I think I will be able to check the script, but it may take a little while for me to be able to do it.
Regards.