On Sat, Jun 18, 2011 at 2:03 PM, Alex Converse <[email protected]> wrote: > 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]>: >>>>>> 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. >> >> The distinction is only relevant if dealing with exactly one >> implementation, which we are not. Quoting gcc simply isn't good >> enough. Besides, even gcc might change in the future. >> > > Because signed integer representation (two's complement; ones's > complement; sign magnitude) is implementation defined this also needs > to to be implementation defined. > > See also: > > 6.5.4 >> Some operators (the unary operator ~, and the binary operators <<, >>, &, ^, >> and |, >> collectively described as bitwise operators) are required to have operands >> that have >> integer type. These operators yield values that depend on the internal >> representations of >> integers, and have implementation-defined and undefined aspects for signed >> types. > > Yet we allow all of these >
Feel free to propose a better solution. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
