Closed Bug 45623 Opened 24 years ago Closed 24 years ago

function returns uninitialized variable

Categories

(NSPR :: NSPR, defect, P3)

x86
Linux
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: marcenuc, Assigned: larryh)

References

Details

Attachments

(2 files)

I'm not sure if it is a bug, but in file
"/cvsroot/mozilla/nsprpub/pr/src/md/unix/uxshm.c", function
"_md_ImportFileMapFromString()" returns "fm" without initializing it in case of
error.

 I have fixed this assigning a default NULL value tu "fm", because this is the
value expected in case of error.
*** Bug 45622 has been marked as a duplicate of this bug. ***
Assignee: wtc → larryh
Status: UNCONFIRMED → NEW
Ever confirmed: true
Larry, please review the attached patch.
I already took a look at it.  I think the
changes for uxshm.c and prmwait.c are fine
but the changes for unix.c and prscanf.c
are unnecessary ('addr' and 'cArg' are never
used uninitialized).
the changes for unix.c and prscanf.c
are unnecessary ('addr' and 'cArg' are never
used uninitialized), but get rid of some compiler
warning about uninitialized variables, which is fine...
reworked the contributed patch to fit the tip.
Wan-Teh, please review.
Status: NEW → ASSIGNED
1. priometh.c: I would add the comments "initialized to an arbitrary
   value to avoid warnings from some compilers".
2. prmwait.c: use the existing identation style in that file.
   do
   {
   } while ( );
3. prscanf.c: I wouldn't change the use of the GET_IF_WITHIN_WIDTH
   macro in GetInt().  (In fact, GetFloat() has similar code that
   would also need to be changed.)
   I would also add the comments that cArg is initialized to an
   arbitrary value to avoid warnings from some compilers.
>3. prscanf.c: I wouldn't change the use of the GET_IF_WITHIN_WIDTH
>   macro in GetInt().  (In fact, GetFloat() has similar code that
>   would also need to be changed.)

I have changed this, to avoid the compiler warning "variable ch may be
uninitialized". The code is right, but I hate all this warnings while
compiling mozilla. If you like, you can explain this in a comment.
What is the compiler you are using?  Did you
turn on some compiler warning flag?

Your compiler is warning about code like this:
    void foo(int boolean_expr)
    {
        int variable;
        int x;

        if (boolean_expr) {
            variable = 3;  /* initialization */
        }
        ...
        if (boolean_expr) {
            x = 2*variable;  /* COMPILER WARNING */
        }
    }

'variable' is only used when 'boolean_expr' is true.
Moreover, 'variable' is initialized before its value
is used.  But the compiler fails to see this.        
Checked in parts to tip of nspr tree.

Checking in pr/src/io/priometh.c;
/cvsroot/mozilla/nsprpub/pr/src/io/priometh.c,v  <--  priometh.c
new revision: 3.13; previous revision: 3.12
done
Checking in pr/src/io/prmwait.c;
/cvsroot/mozilla/nsprpub/pr/src/io/prmwait.c,v  <--  prmwait.c
new revision: 3.12; previous revision: 3.11
done
Checking in pr/src/io/prscanf.c;
/cvsroot/mozilla/nsprpub/pr/src/io/prscanf.c,v  <--  prscanf.c
new revision: 3.9; previous revision: 3.8
done
Checking in pr/src/md/unix/uxshm.c;
/cvsroot/mozilla/nsprpub/pr/src/md/unix/uxshm.c,v  <--  uxshm.c
new revision: 3.7; previous revision: 3.6
done

Checked in the uxshm.c change to the client branch.
(Sorry for my broken english, I'm learning!)

I'm using gcc 2.95.2 for Linux (Debian 2.2).
The command line is:
--------------------
gcc -o Linux2.2.15_x86_PTH_OPT.OBJ/prscanf.o -c  -O2 -fPIC -ansi -Wall -pipe
-DLINUX -Dlinux -Di386 -D_POSIX_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE
-DHAVE_STRERROR -DFORCE_PR_LOG -D_PR_PTHREADS -UHAVE_CVAR_BUILT_ON_SEM -DXP_UNIX
-UDEBUG -DNDEBUG -D_REENTRANT -D_NSPR_BUILD_
-I/mnt/hda7/mozilla/mozilla/mozilla/dist/include
-I../../../pr/include -I../../../pr/include/private  prscanf.c
prscanf.c: In function `GetInt':
prscanf.c:213: warning: `ch' might be used uninitialized in this function
prscanf.c: In function `Convert':
prscanf.c:406: warning: `cArg' might be used uninitialized in this function
--------------------

I agree with you and, as I already said, I know the code is not buggy.
I just want to say: "if there is a simple way to avoid a compiler, then do it!"
I the resulting code is less clean, then just add a few comments to explain why
you do so. This way, your code is still readable, the compiler does not
complain and you can concentrate on serious warnings (like the one that let me
find the bug in uxshm.c).

 Hope this time I was clear! :-))
Hi
Aaarg!

>"if there is a simple way to avoid a compiler, then do it!"
                                           ^^^^^
                                          warning

>I the resulting
 ^^
 If


Sorry again!
The fix for uxshm.c has been checked into the tip,
NSPRPUB_RELEASE_4_0_BRANCH, and NSPRPUB_CLIENT_BRANCH.
Marked the bug fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Target Milestone: --- → 4.0.2
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: