Bug 8976 - uninitialized variable in mount.cifs 5.5
Summary: uninitialized variable in mount.cifs 5.5
Status: RESOLVED FIXED
Alias: None
Product: CifsVFS
Classification: Unclassified
Component: user space tools (show other bugs)
Version: 2.6
Hardware: All All
: P5 normal
Target Milestone: ---
Assignee: Jeff Layton
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-04 18:53 UTC by Jochen Roderburg (mail address dead)
Modified: 2012-10-12 10:49 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jochen Roderburg (mail address dead) 2012-06-04 18:53:03 UTC
The mount.cifs program from the cifs-utils package 5.5 did not work on my Linux system. It just exited without an error message and did not mount anything.

A little debugging brought me to the following "change log" entry:


>> mount.cifs: toggle_dac_capability() stores return code

>> the build process of the cifs-utils for Mandriva 2011 made me notice of
>> the unused variable rc in toggle_dac_capability() of mount.cifs.c.

>> A bit up in the code we store the return value and do not make use of it
>> while calling return.


I think, when this variable rc is now used in this function, it has also to be properly initialized there.

A test with rc = 0 at the beginning of the function made the mount program work again.
Comment 1 Jeff Layton 2012-06-11 11:48:30 UTC
That appears to be correct. rc should be initialized to 0. Do you want to spin up a patch and send it to linux-cifs@vger.kernel.org? Or would you rather I do it?
Comment 2 Jochen Roderburg (mail address dead) 2012-06-11 19:13:27 UTC
(In reply to comment #1)
> That appears to be correct. rc should be initialized to 0. Do you want to spin
> up a patch and send it to linux-cifs@vger.kernel.org? Or would you rather I do
> it?

Hi Jeff,

Please do it.

Although it looks like a trivial patch, I would prefer that one of the program maintainers makes the actual changes.  ;-)
Comment 3 Jeff Layton 2012-10-12 10:49:20 UTC
This should now be fixed...