2011/6/18 Måns Rullgård <[email protected]>: > 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? >
It's not unspecified. It's implementation defined. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
