Alex Converse <[email protected]> writes: > 2011/6/18 Måns Rullgård <[email protected]>: >> 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? >> > > There isn't any signed arithmetic going on here. Just two well defined > type conversions. > > I cited how the spec and gcc explain how both conversions should be > handled. Show me where I'm wrong here? It feels wrong isn't good > enough.
It is unspecified by the C standard, and there are many other compilers than gcc. Can you prove that none of them do something silly here? -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
