Bug 162414
| Summary: | 3 * is used uninitialized in this function + dodgy comparisons | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | David Binderman <dcb314> |
| Component: | xorg-x11 | Assignee: | X/OpenGL Maintenance List <xgl-maint> |
| Status: | CLOSED NOTABUG | QA Contact: | David Lawrence <dkl> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-07-05 07:42:59 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
David Binderman
2005-07-04 11:04:56 UTC
In order to review this, we require you to provide a concrete non-theoretical bug which these or any other compiler warnings cause, and a runtime test case to prove that there is an actual security problem, SEGV, or some other "critical" class issue warranting an allotment of time resources to dedicate to an investigation. Without a test case showing there is a real-world reproduceable runtime problem caused by these warnings, then it should be reported to X.Org upstream bugzilla directly as a minor compile time issue at: http://bugs.freedesktop.org I'm closing this as "NOTABUG", as there is no actual bug being demonstrated here, however if you're able to provide a test case which meets the criteria I've provided above, feel free to reopen the report for re-review. If you do file the bug upstream to X.Org, you may also paste the URL here if you are interested in Red Hat tracking the issue in the X.Org bugzilla. In general, all "trivial" class bugs, including things of this nature, should be reported directly to X.Org. Setting status to "NOTABUG" >we require you to provide ... Fair enough. If reading uninitialised memory, detectable at compile time, isn't important enough for you, then that's fine by me. I had a look at the ChangeLogs for the xorg-x11 project from X.Org, and it seemed to me that only one person ever makes any changes. >provide a test case which meets the criteria I'll put it onto the list of things to be done. (In reply to comment #2) > >we require you to provide ... > > Fair enough. If reading uninitialised memory, detectable > at compile time, isn't important enough for you, then that's > fine by me. It's important (in Red Hat bugzilla) that one can demonstrate an actual real bug caused by a compiler warning, and that the issue will hit users in the real world resulting in either a critical issue or security issue. If neither can be demonstrated, then you're correct that it is not considered important or high priority by us. Such issues are always best filed directly in the upstream project's bug tracker. Even then, it is usually a good idea to indicate the real world implications of the bug there, and proof that there is a real problem even if it is trivial. Developers don't like wasting time on trivial issues that have no major real world impact, especially when there are thousands of issues already present that do have real world impact. The more indication there is in a bug that there is a real problem and that it does or will very likely affect real users, the higher likelyhood someone will pay attention to it and/or fix it. In all cases, critical or trivial, attaching patches to bug reports to fix the reported issues is highly encouraged, especially for the trivial issues and ones with no demonstrable problems. Patches of course should be in standard unified diff (diff -Naur) format, made from the base of the source code tree. (The "xc" dir should be a subdir of where diff is ran from.) > I had a look at the ChangeLogs for the xorg-x11 project from > X.Org, and it seemed to me that only one person ever makes any > changes. A very incorrect assumption. ;o) There are 30-50 developers who make frequent contributions to Xorg, and quite a large number more than that who make less frequent contributions. Some of them commit their changes directly to CVS themselves, and others prefer to log them in bugzilla and let others commit. For stable branches, generally the release manager is responsible for all CVS commits after patches are proposed in bugzilla, moved into approval candidate mode, and accepted. This ensures that the stable branches have a higher level of sanity, and aren't a feature dumping ground. Anyone at all can propose patches for the stable branch. Normally, the majority of proposed patches do get accepted as well, unless there are risks outweighing the benefits or other really good reasons why they shouldn't be. If you're unfamiliar with the Xorg development processes and community of developers, I highly encourage you to join the Xorg mailing lists and get familiar with things. You'll find that people are quite helpful, and volunteers are very welcome (unlike some other OSS X11 implementations out there *cough* <grin>). If you can provide patches to fix the issues that you're reporting, you can potentially get CVS write priveledges quite easily as well, which can potentially save a lot of time and effort compared to filing lots of things in bugzilla, many of which are trivial enough in nature that they might not get attention from other developers who are working on more critical issues, etc. CVS write priveledges are given quite freely in a nature similar to the GNOME project, rather than strict (like other OSS X11 projects out there). If you're interested in joining the project, myself and other developers can assist you in getting started if you like. Join #freedesktop and #xorg-devel on freenode and you'll find many X developers present, and a quite friendly development discussion forum. I recommend idling in the channel for a few days to get a feel also. xorg, xorg-arch.org, and xorg-modular.org are other recommended lists. dri-devel.net for DRI, mesa-dev.net for Mesa as well - if you're interested in those subcomponents too. > >provide a test case which meets the criteria > > I'll put it onto the list of things to be done. Sounds good. Hopefully my above info will help you to get started in the Xorg project too. ;o) We're always looking for new volunteers, and there's plenty of stuff for people of all skill levels including developers, documentation people, testers, bug triagers, etc. Hopefully we can assimilate you into the ranks. ;) Take care, TTYL >It's important (in Red Hat bugzilla) that one can demonstrate an actual >real bug caused by a compiler warning, It seems to me that this is only the case on the xorg-x11 package. All the other packages in Redhat that I report bugs on, they are happy to fix what I find. xorg-x11 is a bigger package than most, however. >Such issues are always best filed directly in the upstream project's >bug tracker. There are over a thousand packages in current Redhat Fedora. I'm not that keen to have a hundred or more new accounts on various bugzillas. >Developers don't like wasting time on trivial issues that have no major real >world impact, especially when there are thousands of issues already present >that do have real world impact. My experience is that if you can move upstream and get the code as correct as possible first, then a lot of downstream fire fighting can be avoided. Your experience may be different. >In all cases, critical or trivial, attaching patches to bug reports UTSL, it's a one line fix in each case. >I highly encourage you to join the Xorg mailing lists I've already got an account on the bugzilla for xorg, and submitted some bug reports there. |