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. -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
