Red Hat Bugzilla – Bug 143474
4 * array subscript out of range
Last modified: 2007-11-30 17:10:57 EST
Description of problem: I just tried to compile package gimp-2.2-0.0.pre2.2 from Redhat Fedora development tree. The compiler said wmf.c(271): warning #175: subscript out of range wmf.c(272): warning #175: subscript out of range wmf.c(273): warning #175: subscript out of range wmf.c(274): warning #175: subscript out of range The source code is values[2].type = GIMP_PDB_INT32; values[2].data.d_int32 = width; values[3].type = GIMP_PDB_INT32; values[3].data.d_int32 = height; But static GimpParam values[2]; So values[2] and values[3] do not exist. Suggest code re-work. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Please check whether this problem is still existent in gimp-2.2.0-1 which is available from Rawhide since yesterday. In that case, please raise the issue upstream (http://bugs.gimp.org) and/or submit a patch.
>Please check whether this problem is still existent in gimp-2.2.0-1 Volunteer projects, eh ? Sorry, I don't have time or resource to do this. It would be a pity if this bug report just got ignored.
Apparently you have the time to rebuild our packages with a 3rd party compiler (this is not a gcc warning). As you correctly pointed out, Fedora _is_ a volunteer project. From http://fedora.redhat.com/about/: "The community is defined as those who not only consume but also produce for the good of other community members." I.e. if there isn't a regression or the bug not only concerns parts of the program a minority of people will be using (who needs Windows Meta Files anyway nowadays), the bug report is pretty low on my list of things to do because my time is limited as well (and I guess this applies to all package maintainers here). As I see it, submitting your reports here instead of upstream without any patches etc. from you is a big waste of resources, because submitting them upstream would be no more of an effort to you than submitting them here, but it leaves us to forward the bug report to upstream and to keep both bug reports in sync. Whereas if you submitted it upstream from the start, we would get the fix eventually anyway. Don't get me wrong here, I suggest this only because this _is_ a bug that's trivial to fix but at the same time doesn't seem to have visible regressions yet, so we actually can afford to wait until upstream contains a fix. The only question remaining to me is whether your actual motivation is getting the bug fixed or rather using the packages as a testload for whatever compiler you use (why would you build this with another compiler if not for that reason?).
>submitting them upstream would be no more of an effort to you than >submitting them here If it were the case that this package was the only package I ever found bugs in, then what you write would be true. Nearly all Redhat developers just fix the bug reports I send them. A few don't - not my problem. >why would you build this with another compiler All compilers have strengths and weaknesses. Getting a different opinion, from a second compiler, is an easy way to flush out a load of obvious compile time bugs.
The issue is that this particular piece of software is not being developed at Red Hat, not even to a small part -- there are some programs we only package, some we develop partially and some we develop virtually alone. In the first case we package it, we care about regressions, but we cannot be a proxy between you and upstream, especially if you do such a large number of packages. Because you seem to do it on a regular basis I presuma at least some proficiency in the field on your behalf and I expect a certain level of actual participation in solving the problem whether it's by submission upstream or by providing a patch. Anything less is just not helpful at all: - It doesn't help us -- we've got a minimum bug report, need to build a patch, have to submit it upstream all the while you could it submit it there by yourself with hardly more effort to people who actually _know_ the code. - It doesn't help you either -- you submit bug reports that probably don't get acted upon. - And last but not least it doesn't help other users because if we tend to ignore bug reports as yours bugs that really do cause regressions might not be looked at.
>there are some programs we only package, some we develop partially >and some we develop virtually alone. I afraid I have no way to distinguish these cases. Perhaps a flag would help ? On the one hand the Fedora project continues to solicit bug reports and patches, but on the other hand, if I submit a bug report for a certain unknown subset of packages, then that bug report gets ignored, because I send it to Redhat, not the original maintainers. This sounds slightly less than optimal. I would be happy if my bug reports for the unknown set merely got forwarded onto their respective maintainers. I am happy to continue as I am. Some bug reports will fall on stony ground. Fair enough.