Bug 141587 - local variable used before set
local variable used before set
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: evolution-data-server (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Malcolm
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-02 05:28 EST by David Binderman
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-13 17:02:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 344132 None None None Never

  None (edit)
Description David Binderman 2004-12-02 05:28:55 EST
Description of problem:

I just tried to compile package evolution-data-server-1.0.2-3 from 
Redhat Fedora Core 3.

The compiler said

e-cal-backend-groupwise.c(1436): remark #592: variable "comp_str" is
used before its value is set

The source code is

	char *comp_str;
    status = e_cal_backend_groupwise_modify_object (E_CAL_BACKEND_SYNC
(cbgw), 
				cal, comp_str, CALOBJ_MOD_THIS, &comp_str);

I agree with the compiler. This code would benefit from rework.



Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Matthew Miller 2006-07-10 19:34:38 EDT
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!
Comment 2 David Binderman 2006-07-11 04:18:58 EDT
(In reply to comment #1)
> If this problem is a security issue, please reopen and
> reassign to the Fedora Legacy product. If it is not a security issue and
> hasn't been resolved in the current FC5 updates or in the FC6 test
> release, reopen and change the version to match.

Thanks for your kind offer, but I think it is worth noting
that it has taken Redhat twenty months to reply to this bug report.

The speed of reply makes me reluctant to help out with any Redhat 
project in the future.

For the record, the openSuse project appears to provide
a same day service for bug reports.
Comment 3 Matthew Miller 2006-07-11 12:04:21 EDT
This is certainly an area where Fedora could use improvement.

This process of reviewing old bugs is a small effort towards making sure things
don't compeletely slip through the cracks.
Comment 4 David Binderman 2006-07-11 17:45:26 EDT
(In reply to comment #3)
> This process of reviewing old bugs is a small effort towards making sure things
> don't compeletely slip through the cracks.

After twenty months, I suspect I am fairly safe in assuming that
the bug report has gone stale.

It is not entirely clear to me that triaging old bug reports
is the most effective use of resources.

This may be a resource allocation problem for Redhat.


Comment 5 Matthew Miller 2006-07-11 21:50:43 EDT
Perhaps. I don't work for Red Hat, so I can't speak to their resource allocation
issues. I do help out with Fedora, though, and this triaging is part of Fedora
Legacy. As part of that, though, I *do* hope to keep bug reports from completely
falling on the floor, and in general this project has been quite successful.

Twenty months is a long time, and someone should have responded to at least say:
1) thanks for the report; that does look problematic, 2) this is the sort of
thing that is generally better addressed upstream, as it does not appear to be a
Fedora-specific issue, and 3) let's work out some way of getting this bug
reported upstream.
Comment 6 Matthew Miller 2006-07-13 17:02:35 EDT
Anyway, looks like the code in question doesn't exist in
evolution-data-server-1.7.3-3.1 in FC6-devel. I presume someone upstream did,
eventually, rework things.
Comment 7 Marcin Garski 2006-08-29 09:04:43 EDT
20 months is a very long time, and you do a great job tracking such bugs, but in
such projects as GNOME or KDE that are actively maintained it's better to report
such bugs upstream.
I have filed bug report for this bug in GNOME Bugzilla
(http://bugzilla.gnome.org/show_bug.cgi?id=344132), and it took only two months
to resolve it. In addition, filling bug upstream makes fixes available for all
users "out-of-box" not only Fedora Core users.
Comment 8 David Binderman 2006-08-29 10:59:26 EDT
(In reply to comment #7)
> projects as GNOME or KDE that are actively maintained it's better to report
> such bugs upstream.

I can appreciate your point of view, but I have quite a few projects
on the go usually.

For instance, there are a thousand or so packages in Redhat the last time
I looked.

If I do what you suggest, that implies that I need a seperate 
account for each bug report I find. That might be 200-500 seperate accounts.

I prefered to merely forward the bug reports to Redhat and let them
sort it out or not, as the case may be.
Comment 9 Marcin Garski 2006-08-29 12:05:54 EDT
(In reply to comment #8)
> If I do what you suggest, that implies that I need a seperate 
> account for each bug report I find. That might be 200-500 seperate accounts.

200-500 seperate accounts is far too many, but maybe partial solution for you is
to register in KDE, GNOME and freedesktop.org Bugzilla's (currently I don't
remember others with such many projects) so you will have only four accounts and
you have access to hundred projects, then filling bug reports in their BZ will
unload Red Hat's Bugzilla. What do you think about this?
Comment 10 David Binderman 2006-08-29 14:07:43 EDT
(In reply to comment #9)
>What do you think about this?

Thanks for your advice. It is the same advice I have received
before from other Redhat contributors.

My contribution effort to Redhat finished quite some time ago, 
and I have no wish to change that.

Note You need to log in before you can comment on or make changes to this bug.