Alex Converse <[email protected]> writes: > 2011/6/18 Måns Rullgård <[email protected]>: >> Yusuke Nakamura <[email protected]> writes: >> >>> 2011/6/18 Måns Rullgård <[email protected]> >>> >>>> Yusuke Nakamura <[email protected]> writes: >>>> >>>> > This patch fixes my 10L of following. >>>> > >>>> http://git.libav.org/?p=libav.git;a=commitdiff;h=5f0bb0baefd506d684adfa1ad4259c65973b455e >>>> > >>>> > From f3c030ebedabc9a17e377c6f91dc417e6578712b Mon Sep 17 00:00:00 2001 >>>> > From: Yusuke Nakamura <[email protected]> >>>> > Date: Sun, 5 Jun 2011 01:28:43 +0900 >>>> > Subject: [PATCH] mov: Fix empty edit detection. >>>> > >>>> > --- >>>> > libavformat/mov.c | 2 +- >>>> > 1 files changed, 1 insertions(+), 1 deletions(-) >>>> > >>>> > diff --git a/libavformat/mov.c b/libavformat/mov.c >>>> > index e6ada4e..2d1d726 100644 >>>> > --- a/libavformat/mov.c >>>> > +++ b/libavformat/mov.c >>>> > @@ -2230,7 +2230,7 @@ static int mov_read_elst(MOVContext *c, AVIOContext >>>> *pb, MOVAtom atom) >>>> > time = avio_rb64(pb); >>>> > } else { >>>> > duration = avio_rb32(pb); /* segment duration */ >>>> > - time = avio_rb32(pb); /* media time */ >>>> > + time = (int32_t)avio_rb32(pb); /* media time */ >>>> >>>> This cast is invalid if the value is >INT_MAX. >>> >>> What's wrong? If I get 0x80000000 from avio_rb32(pb), then I want to set >>> 0xffffffff80000000 to int64_t time. >> >> The cast is not guaranteed to do that. > > On GCC it is...
Are you sure about that? What about all those cases where it optimises assuming signed integer arithmetic will never overflow since the results are undefined/unspecified if it does? > Do you know a compiler we support where it isn't? We do this all over > the code base. We should not be doing that then. -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
