Bug 141584 - local variable used before set
local variable used before set
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: balsa (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: John Dennis
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-02 05:22 EST by David Binderman
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-12-02 10:55:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

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

I just tried to compile package balsa-2.2.4-1.FC3.1 from 
Redhat Fedora Core 3.

The compiler said

main.c(489): remark #592: variable "mbnode" is used before its value
is set

The source code is

    BalsaMailboxNode *mbnode;

    g_return_val_if_fail(mbnode, FALSE);

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 John Dennis 2004-12-02 10:55:14 EST
Then by all means file a bug report with the upstream project that
owns the software: http://balsa.gnome.org. Compiler warnings in
external software are not the type of problem that makes sense for us
to fix, the cost/benefit is not justified.
Comment 2 David Binderman 2004-12-02 14:59:27 EST
>Compiler warnings in
>external software are not the type of problem that makes sense for us
>to fix, the cost/benefit is not justified.

Dozens of other folks at Redhat have a different opinion.
I get bug fixes from them.

What's different about balsa that makes obvious bugs hard
to fix ?
Comment 3 John Dennis 2004-12-02 15:46:23 EST
> Dozens of other folks at Redhat have a different opinion.
> I get bug fixes from them.

Well I don't know who you are, but it sounds like you're upstream,
thats the difference. It's much easier to inform upstream of issues
that should be fixed than it is for us to create the equivalent of an
ECO (Engineering Change Order) and track all this ourselves.

> What's different about balsa that makes obvious bugs hard
> to fix ?

Because we have to create the patch, distribute the rpm, send the
patch upstream so on the next release we don't have apply the patches
again (many patches don't apply cleanly on subsequent upstream
releases). Track the process of the patch, probably open an upstream
bug report for the patch, track that, etc. It's a lot of work for us
and it could be handled directly upstream without our involvement. We
have to pick and choose what we spend money on, compiler warnings on a
second tier mail client do not trump much more serious bugs or bugs in
our primary mail client, I'm sorry if that sounds harsh, I don't mean
to be, it just the way it is :-( You should proably know that Balsa is
a very low priority, if we can just rebuild it great, but if it
consumes any significant engineering resources its going to get pulled
from the distribution and I don't think that serves your interest.
There is a significant Balsa bug open now where it crashes, that needs
attention that has be hard to find, compiler warnings given the
current scenario don't pass the sanity test. Once again I'm sorry,
please accept my appology, but going upstream will be vastly more
productive in this instance.

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