Open
Bug 713308
Opened 13 years ago
Updated 2 years ago
Clang Static Analysis: Assigned value is garbage or undefined in modules/libbz2/src/compress.c
Categories
(Core :: General, defect)
Core
General
Tracking
()
NEW
People
(Reporter: decoder, Unassigned)
References
(Blocks 1 open bug, )
Details
The following report (in the URL field) has been generated by static analysis using Clang. It would be good if someone familiar with the particular code could check if - this is really a bug or a false positive - and/or if it makes sense to adjust the code (even if there is not a real bug present, e.g. by adding a missing initialization). In this particular report, the analyzer first seems to assume | s->nInUse = 1 | which makes the for loop at line 161 | for (i = 0; i < s->nInUse; i++) yy[i] = (UChar) i; | assign only | yy[0] = (UChar) 0; |. From that point on, the analyzer plots a path through the code reaching line 193 with | rtmp = yy[1]; | which is an undefined assignment because yy[1] hasn't been initialized. Can this happen or is the initial assumption already impossible? Even if it's not a bug, is there any way to make the code better here or do you think no change is required?
Comment 1•13 years ago
|
||
I haven't looked at this in detail, but I do see in the URL you give that we have [5] Assuming i <= EOB followed by [7] Assuming i > EOB I'd have to study the sources, but I'm pretty sure this is due to some other condition that can never be true, eg the block to be compressed cannot have zero size. Also bearing in mind that (1) this is the compression size of the library, so should be able to handle any inputs, and has been tested with a bunch of specially constructed test cases, including zero sized files, etc, both natively and when running on Valgrind/Memcheck, and I have never seen any uninitialised value problems (2) I am not aware of any inputs for which bzip2-decompress(bzip2-compress(x)) != x for at least a decade (3) the code has been analysed by at least one other static analyser (Klockwork) and I have not been informed of any such problem I think you should forget about this. What I _would_ say though is that the version in Fx should be upgraded to the latest stable (1.0.6). There have been some improvements to the safety of the decompression side following fuzzing tests, and we should really take those.
Comment 2•13 years ago
|
||
> (1) this is the compression size of the library, so should be able to
s/size/side, duh.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•