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