After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 742367 - wavparse: initialize variables
wavparse: initialize variables
Status: RESOLVED INVALID
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
unspecified
Other Windows
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-01-05 11:23 UTC by Vineeth
Modified: 2015-01-06 14:36 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
initialize variables (1.01 KB, patch)
2015-01-05 11:24 UTC, Vineeth
none Details | Review

Description Vineeth 2015-01-05 11:23:11 UTC
cur and stop variable are not initialized.
This may result in wrong calculations at lines 437 and 441 respectively.

Hence initializing the variables to 0, during declaration.
Comment 1 Vineeth 2015-01-05 11:24:14 UTC
Created attachment 293801 [details] [review]
initialize variables
Comment 2 Luis de Bethencourt 2015-01-05 12:11:29 UTC
You are correct about that if variable event is False, variables cur and stop aren't set by gst_event_parse_seek(). But, event being False also means line 421:

    if (!event || wav->state != GST_WAVPARSE_DATA) {

Will resolve to True and the true statement block will be run. Meanwhile the lines you are worried about (437 and 441) are in the false statement block of that conditional.

There is no combination of values where cur and stop are used without being initialized.

At least I don't see any situation where this might be a problem. If you know of any please say so :) If not I will close this bug.

Thanks for looking into this.
Comment 3 Vineeth 2015-01-06 03:52:59 UTC
Hi Luis,


Thanks for the review. As you have mentioned, this case will not arise :)

sorry about the wrong bug :).
Comment 4 Luis de Bethencourt 2015-01-06 14:36:19 UTC
No worries Vineeth :) Thanks for looking at the code and helping.