Bug 158609

Summary: dvbstream-0.6-6: array subscript out of range
Product: [openSUSE] SUSE LINUX 10.0 Reporter: David Binderman <dcb314>
Component: BasesystemAssignee: Torsten Duwe <duwe>
Status: RESOLVED UPSTREAM QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P2 - High    
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: SuSE Linux 10.1   
URL: https://sourceforge.net/tracker/?func=detail&aid=2885125&group_id=50669&atid=460565
Whiteboard:
Found By: Other Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description David Binderman 2006-03-16 12:40:05 UTC
I just tried to compile package dvbstream-0.6-6 with the Intel C compiler.

It said

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;

I agree with the compiler. b[ 3] does not exist.
Suggest code rework.

I have reported this once before, as part of bug 129939, but nothing seems
to have happened for five months.
Comment 1 David Binderman 2006-05-15 18:21:53 UTC
Still broken in the version shipped in Suse Linux 10.1
Comment 2 Torsten Duwe 2006-05-16 10:49:11 UTC
Moving it back to the screening team is counterproductive.
Comment 3 David Binderman 2006-10-31 11:07:24 UTC
Still broken in Suse Linux 10.2 Beta 1.

How long should this bug remain before someone 
fixes it ?
Comment 4 Stefan Dirsch 2007-01-16 22:32:49 UTC
Feel free to close as duplicate of Bug #235591.
Comment 5 David Binderman 2009-06-11 10:59:48 UTC
(In reply to comment #4)
> Feel free to close as duplicate of Bug #235591.

Still broken a couple of years later in version 0.6-138.42
Comment 6 Richard Biener 2009-10-17 14:53:21 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.