Closed Bug 45623 Opened 25 years ago Closed 25 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: 25 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: