Merge lp://staging/~tyhicks/ecryptfs/cid1375979 into lp://staging/ecryptfs
Proposed by
Tyler Hicks
| Status: | Merged |
|---|---|
| Merged at revision: | 894 |
| Proposed branch: | lp://staging/~tyhicks/ecryptfs/cid1375979 |
| Merge into: | lp://staging/ecryptfs |
| Diff against target: |
12 lines (+0/-2) 1 file modified
src/libecryptfs/cmd_ln_parser.c (+0/-2) |
| To merge this branch: | bzr merge lp://staging/~tyhicks/ecryptfs/cid1375979 |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Jason Xing (community) | Approve | ||
|
Review via email:
|
|||
Description of the change
Remove unreachable code when parsing mount opt name value pairs
Revision 886 introduced a change to the mount option parsing code for
name-value pairs. A break was added to a loop once the first '=' is seen.
Before the break was added, it was possible that a '=' would be seen, then
memory allocated for the name portion of the string, then another '=' could be
seen and the previous name string be freed and then reallocated. However,
there's no longer a chance of needed to reallocate the name string so the
free() is not needed.
Discovered by Coverity (CID 1375979)
To post a comment you must log in.
Revision history for this message
| Tyler Hicks (tyhicks) wrote | # |
Preview Diff
[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
Thanks, Tyler.
You're right. We don't need to reallocate the memory for previous name string because we "break" the loop if we match the first "=". So the patch looks good for me :)