Bug 129939 - dvbstream: array subscript out of range + local variable used before set
Summary: dvbstream: array subscript out of range + local variable used before set
Status: RESOLVED UPSTREAM
Alias: None
Product: openSUSE 11.0
Classification: openSUSE
Component: Network (show other bugs)
Version: Factory
Hardware: All openSUSE 11.0
: P2 - High : Minor (vote)
Target Milestone: ---
Assignee: Torsten Duwe
QA Contact: E-mail List
URL: https://sourceforge.net/tracker/?func...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-21 09:53 UTC by David Binderman
Modified: 2009-10-23 23:44 UTC (History)
0 users

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description David Binderman 2005-10-21 09:53:30 UTC 
I just tried to compile package dvbstream-0.4pre2-390 with the Intel 
C compiler 

It said

1.

mpegtools/remux.c(468): warning #175: subscript out of range

The source code is

                uint8_t b[3];

                vring_peek( rem, b, 4, 0);
                if ( b[0] == 0x00 && b[1] == 0x00 && b[2] == 0x01
                     && b[3] == 0xb3) found = 4;

Clearly broken code. b[ 3] doesn't exist. Suggest code rework, but I don't have
a suggested fix for this.

2.

tune.c(202): warning #592: variable "fe_info" is used before its value is set

The source code is

      switch(fe_info.type) {

Suggest initialise local variable "fe_info" before first use.
Comment 1 David Binderman 2005-12-13 15:26:39 UTC 
part 1 of this bug report still exists in version 0.6-2, around 13 Dec 05
Comment 2 Richard Biener 2009-10-17 14:53:13 UTC 
David, in case the issues are not introduced by a patch local to openSUSE please report the issues upstream.

Packagers, please do not add openSUSE-local patches to fix this kind of errors but forward the bugs upstream
and close the bugs as RESOLVED UPSTREAM.

Note that it is perfectly fine to have "resource leaks" at the end of a program as the kernel will clean
up for you.  Manually freeing them only increases binary size and runtime.