GNOME Bugzilla – Bug 698758
Wrong limit for "Native Windows wider or taller than 65535 pixels are not supported"
Last modified: 2013-08-14 02:55:27 UTC
Callling gdk_window_move_resize with crazy sizes gives you Native Windows wider or taller than 65535 pixels are not supported and the width/height get clipped at 65535. Which is fine, except... The limit is wrong. It should have been 32767. Go beyond that and I see an instant BadValue error and the program dies.
*** Bug 648381 has been marked as a duplicate of this bug. ***
*** Bug 604641 has been marked as a duplicate of this bug. ***
This bug presents a DoS vulnerability for some gtk consumers and a patch has been submitted more than two years ago in Bug 648381. Given that Bug 648381 also contains an example program to reproduce the issue I'm puzzled why the status is still UNCONFIRMED.
(In reply to comment #3) > Given that Bug 648381 also contains an example program to reproduce the issue > I'm puzzled why the status is still UNCONFIRMED. gtk developers don't use the NEW status: bugs go from UNCONFIRMED to either NEEDINFO or RESOLVED. as for Windows bugs: there is a lack of backend maintainers, so patches go in after they have been tested by at least a couple of people using the win32 backend of GDK and confirmed to be working.
oh, sorry, I thought it was for the Windows backend, not for the X11 one. there is no version set either. the patch in bug 648381 needs work.
It's a three-line patch (plus changes in an error path). It doesn't really need work as much as it needs to be applied. (But, yeah, using MIN is fine. Macro vs variable is not substantial, but as a variable it should be given a type instead of implied int.)
since we are the people maintaining this code, and not you, we'd like code to follow our style, conventions, and behaviour. this means that patches have to be functionally correct *and* stylistically correct before being applied.
Created attachment 250057 [details] [review] Minimally invasive patch This patch preserves all coding style, all convensions, and all behaviour (except for the bug being fixed).
Emmanuele Bassi: it is not reasonable to ask for minor stylistic changes in a patch like the one over in bug 648381. (1) it takes you longer to ask than to change to your heart's content; (2) the patch is TWO YEARS OLD. After two years it isn't reasonable to simply assume that the submitter will get the mail. And hasn't moved on. You are asking him to reestablish a development environment, change the patch, re-test, resubmit, wait two more years[*], and hope the patch will pass muster with the coding conventions in place at that time. Rinse and repeat. That is blatant disregard for other people's effort. He identified the problem, he reported the problem coherently, he devised an effective fix. That kind of effort deserves a better response.[**] [*] The only available data to base an estimate on is how long it took the first time. [**] And he is in all likelihood a nicer person than I am.
thanks for the patch
*** Bug 601616 has been marked as a duplicate of this bug. ***