Description of problem:
I just tried to compile package xorg-x11-6.8.2-31 from Redhat
Fedora Core development tree with the gcc 4.0.0 compiler and the
compiler flag -Wall.
The compiler said
usb-other.c:142: warning: 'absolute' is used uninitialized in this function
usb-other.c:143: warning: 'absolute' is used uninitialized in this function
usb-other.c:144: warning: 'absolute' is used uninitialized in this function
The source code is
info->minval[1+j] = absolute;
info->maxval[1+j] = absolute;
info->res[1+j] = absolute;
I agree with the compiler. Suggest initialise local variable
"absolute" before first use.
core.c:3243: warning: comparisons like X<=Y<=Z do not have their mathematical
The source code is
if (FCOMPARE(lambda, item, CAR(list), code) == expect)
Suggest rework code for maintainability.
core.c:3256: warning: comparisons like X<=Y<=Z do not have their mathematical
Version-Release number of selected component (if applicable):
Steps to Reproduce:
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:
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
>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
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
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. firstname.lastname@example.org,
email@example.com, and firstname.lastname@example.org are other recommended
lists. email@example.com for DRI, firstname.lastname@example.org 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. ;)
>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
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.