[Gstreamer-bugs] [Bug 102719] Changed - [PATCH] gst_mpeg_parse_parse_packhead reads outside the buffer

[bugzilla-daemon at widget.gnome.org]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=102719

Changed by vishnu at pobox.com.

--- shadow/102719	Fri Jan 17 10:31:19 2003
+++ shadow/102719.tmp.24606	Fri Jan 17 10:52:41 2003
@@ -37,6 +37,34 @@
 this could be a problem ?
 - isn't there a possibility for a workaround to check this, and then
 use an endian-correct way to get at the data ? An alternative might be
 to allocate one byte more by default for the buffer or something.
 - please don't use // :)
 
+
+------- Additional Comments From vishnu at pobox.com  2003-01-17 10:52 -------
+> - the GUINT-macro's are very useful for endianness, so not using them
+> will probably cause us a lot of problems in that area.  So I think we
+> should keep using them.
+
+That's nonsense.  When reading single bytes then there is no such
+thing as endianness.  Bytes in the stream are always ordered the same
+way.  So my patch is also an optimization (unless the compiler
+optimizes out the byte-swapping).
+
+So if this is the reason you've been waiting to commit my patch ..
+please commit!
+
+>  can you say how it can happen that the 4th byte is out of range ? I
+> suspect valgrind put you on the track, but did you also find out why
+> this could be a problem ?
+
+Valgrind found it.  It just happens that the 4th byte is outside the
+buffer occationally when indexing (or playing, i suppose) a large
+media file.  Try scanning through a VCD or DVD and you'll hit the
+crash.  i don't have any deeper explanation because i don't understand
+most of the MPEG parsing code.  i'm just making a technical fix.
+
+> please don't use // 
+
+Yah, sorry.  It's hard to break good habits.  ;-)
+