On Mon, Dec 16, 2019 at 12:05:52AM +0100, Andreas Rheinhardt wrote: > On Sun, Dec 15, 2019 at 11:53 PM Michael Niedermayer <mich...@niedermayer.cc> > wrote: > > > On Sat, Dec 14, 2019 at 11:19:14PM +0100, Andreas Rheinhardt wrote: > > > bytestream2_get_bytes_left returns an unsigned int; as a result, > > > it returns big positive numbers if an overread already happened, > > > making it unsuitable for scenarios where one wants to allow this > > > in a controlled way (because the buffer is actually padded so that > > > no segfaults can happen). So change it to return an ordinary int. > > > > > > Also, bytestream2_get_bytes_left_p has been modified in the same way. > > > > > > Signed-off-by: Andreas Rheinhardt <andreas.rheinha...@gmail.com> > > > --- > > > Implemented James' suggestion to return an int. I have not found a place > > > where this would pose a problem. > > > > How do we know that this doesnt break any code ? > > > > Well, first of all, the init functions take ints and assert that they are > >= 0, so the ordinary return value of bytestream2_get_bytes_left[_p] is > representable in an int. Second, I ran fate with asan and have only found a > memleak in the hls muxer (will send a patch soon), but no problem with this > patch. And finally, I have not found a problem in the places where these > functions are used that I looked at. If you want all to be checked, then > say so. I don't know how long this would take, though.
what is the oppinion of other devs ? this is likely ok but some issue could be hiding in one of the many uses of this. Checking all would be a lot of work with little expected return Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once" - "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
