On Thu, May 14, 2020 at 12:46:56PM -0700, Dale Curtis wrote:
> On Thu, May 14, 2020 at 11:47 AM Michael Niedermayer
> wrote:
>
> > On Fri, May 01, 2020 at 11:42:43AM -0700, Dale Curtis wrote:
> > > On Fri, May 1, 2020 at 10:57 AM Carl Eugen Hoyos
> > wrote:
> > >
> > > > Could you confirm that y
On Thu, May 14, 2020 at 11:47 AM Michael Niedermayer
wrote:
> On Fri, May 01, 2020 at 11:42:43AM -0700, Dale Curtis wrote:
> > On Fri, May 1, 2020 at 10:57 AM Carl Eugen Hoyos
> wrote:
> >
> > > Could you confirm that you attached the wrong patch?
> > >
> >
> > No, I sent the patches without com
On Fri, May 01, 2020 at 11:42:43AM -0700, Dale Curtis wrote:
> On Fri, May 1, 2020 at 10:57 AM Carl Eugen Hoyos wrote:
>
> > Could you confirm that you attached the wrong patch?
> >
>
> No, I sent the patches without completing the rebase. Sorry.
>
> - dale
> common.h | 36 +
On Wed, May 13, 2020 at 3:55 PM Michael Niedermayer
wrote:
> On Fri, May 08, 2020 at 05:21:06PM -0700, Dale Curtis wrote:
> > On Wed, May 6, 2020 at 7:03 AM Michael Niedermayer
>
> > wrote:
> >
> > > On Mon, May 04, 2020 at 04:06:56PM -0700, Dale Curtis wrote:
> > > > On Mon, May 4, 2020 at 3:39
On Fri, May 08, 2020 at 05:21:06PM -0700, Dale Curtis wrote:
> On Wed, May 6, 2020 at 7:03 AM Michael Niedermayer
> wrote:
>
> > On Mon, May 04, 2020 at 04:06:56PM -0700, Dale Curtis wrote:
> > > On Mon, May 4, 2020 at 3:39 PM Michael Niedermayer
> >
> > > wrote:
> > >
> > > > On Mon, May 04, 20
On Fri, May 8, 2020 at 5:21 PM Dale Curtis wrote:
> On Wed, May 6, 2020 at 7:03 AM Michael Niedermayer
> wrote:
>
>> On Mon, May 04, 2020 at 04:06:56PM -0700, Dale Curtis wrote:
>> > On Mon, May 4, 2020 at 3:39 PM Michael Niedermayer
>>
>> > wrote:
>> >
>> > > On Mon, May 04, 2020 at 02:19:47PM
On Wed, May 6, 2020 at 7:03 AM Michael Niedermayer
wrote:
> On Mon, May 04, 2020 at 04:06:56PM -0700, Dale Curtis wrote:
> > On Mon, May 4, 2020 at 3:39 PM Michael Niedermayer
>
> > wrote:
> >
> > > On Mon, May 04, 2020 at 02:19:47PM -0700, Dale Curtis wrote:
> > > > On Mon, May 4, 2020 at 1:48
On Mon, May 04, 2020 at 04:06:56PM -0700, Dale Curtis wrote:
> On Mon, May 4, 2020 at 3:39 PM Michael Niedermayer
> wrote:
>
> > On Mon, May 04, 2020 at 02:19:47PM -0700, Dale Curtis wrote:
> > > On Mon, May 4, 2020 at 1:48 PM Michael Niedermayer
> >
> > [...]
> >
>
> You snipped out the exampl
On Mon, May 4, 2020 at 3:39 PM Michael Niedermayer
wrote:
> On Mon, May 04, 2020 at 02:19:47PM -0700, Dale Curtis wrote:
> > On Mon, May 4, 2020 at 1:48 PM Michael Niedermayer
>
> [...]
>
You snipped out the example I provided, but did you have an opinion on
which approach looked best there? I
On Mon, May 04, 2020 at 02:19:47PM -0700, Dale Curtis wrote:
> On Mon, May 4, 2020 at 1:48 PM Michael Niedermayer
[...]
>
>
> > lets consider a simple random expression
> > a*x + b*y
> >
> > overflow = av_checked_sat_mul64(a, x, &T0);
> > overflow |= av_checked_sat_mul64(b, y, &T1);
> > overflo
On Mon, May 4, 2020 at 1:48 PM Michael Niedermayer
wrote:
> this could be done, but iam unsure this API is optimal
>
> Maybe its best to show an example, why iam unsure about the API
>
Thanks, but maybe a more concrete case to look at would be the patch I sent
for fixing skip samples: "Avoid int
On Fri, May 01, 2020 at 01:13:58PM -0700, Dale Curtis wrote:
> On Fri, May 1, 2020 at 12:53 PM Michael Niedermayer
> wrote:
>
> > On Thu, Apr 30, 2020 at 05:39:43PM -0700, Dale Curtis wrote:
> > > On Thu, Apr 30, 2020 at 5:21 PM James Almer wrote:
> > >
> > > > On 4/30/2020 7:19 PM, Dale Curtis
Bump. I have 5 integer overflow fuzzing issues awaiting our resolution of
this discussion. Thanks.
- dale
On Fri, May 1, 2020 at 1:13 PM Dale Curtis wrote:
> On Fri, May 1, 2020 at 12:53 PM Michael Niedermayer
> wrote:
>
>> On Thu, Apr 30, 2020 at 05:39:43PM -0700, Dale Curtis wrote:
>> > On T
On Fri, May 1, 2020 at 12:53 PM Michael Niedermayer
wrote:
> On Thu, Apr 30, 2020 at 05:39:43PM -0700, Dale Curtis wrote:
> > On Thu, Apr 30, 2020 at 5:21 PM James Almer wrote:
> >
> > > On 4/30/2020 7:19 PM, Dale Curtis wrote:
> > > > Many places are using their own custom code for handling ove
On Thu, Apr 30, 2020 at 05:39:43PM -0700, Dale Curtis wrote:
> On Thu, Apr 30, 2020 at 5:21 PM James Almer wrote:
>
> > On 4/30/2020 7:19 PM, Dale Curtis wrote:
> > > Many places are using their own custom code for handling overflow
> > > around timestamps or other int64_t values. There are enoug
On Fri, May 1, 2020 at 10:57 AM Carl Eugen Hoyos wrote:
> Could you confirm that you attached the wrong patch?
>
No, I sent the patches without completing the rebase. Sorry.
- dale
sat_math_v4.patch
Description: Binary data
___
ffmpeg-devel mailing
Am Fr., 1. Mai 2020 um 19:41 Uhr schrieb Dale Curtis :
>
> On Fri, May 1, 2020 at 10:32 AM James Almer wrote:
>
> > On 5/1/2020 2:23 PM, Dale Curtis wrote:
> > > On Fri, May 1, 2020 at 6:12 AM James Almer wrote:
> > >
> > >> On 5/1/2020 6:36 AM, Carl Eugen Hoyos wrote:
> > >>>
> > >>> The macro e
On Fri, May 1, 2020 at 10:32 AM James Almer wrote:
> On 5/1/2020 2:23 PM, Dale Curtis wrote:
> > On Fri, May 1, 2020 at 6:12 AM James Almer wrote:
> >
> >> On 5/1/2020 6:36 AM, Carl Eugen Hoyos wrote:
> >>>
> >>> The macro exists to avoid separate patches?
> >>
> >> No, it exists to not require
On 5/1/2020 2:23 PM, Dale Curtis wrote:
> On Fri, May 1, 2020 at 6:12 AM James Almer wrote:
>
>> On 5/1/2020 6:36 AM, Carl Eugen Hoyos wrote:
>>>
>>> The macro exists to avoid separate patches?
>>
>> No, it exists to not require configure checks just to enable a path for
>> gcc/clang and another
On Fri, May 1, 2020 at 6:12 AM James Almer wrote:
> On 5/1/2020 6:36 AM, Carl Eugen Hoyos wrote:
> >
> > The macro exists to avoid separate patches?
>
> No, it exists to not require configure checks just to enable a path for
> gcc/clang and another for other compilers.
>
Since consensus seems to
On 5/1/2020 6:36 AM, Carl Eugen Hoyos wrote:
> Am Fr., 1. Mai 2020 um 01:31 Uhr schrieb James Almer :
>>
>> On 4/30/2020 8:20 PM, Carl Eugen Hoyos wrote:
>>> Am Fr., 1. Mai 2020 um 00:20 Uhr schrieb Dale Curtis
>>> :
Many places are using their own custom code for handling overflow
Carl Eugen Hoyos (12020-05-01):
> This patch is not ok, please split it.
What benefit would it serve?
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mail
Am Fr., 1. Mai 2020 um 02:46 Uhr schrieb Dale Curtis :
>
> On Thu, Apr 30, 2020 at 5:21 PM James Almer wrote:
>
> > On 4/30/2020 7:19 PM, Dale Curtis wrote:
> > > Many places are using their own custom code for handling overflow
> > > around timestamps or other int64_t values. There are enough of
Am Fr., 1. Mai 2020 um 01:31 Uhr schrieb James Almer :
>
> On 4/30/2020 8:20 PM, Carl Eugen Hoyos wrote:
> > Am Fr., 1. Mai 2020 um 00:20 Uhr schrieb Dale Curtis
> > :
> >>
> >> Many places are using their own custom code for handling overflow
> >> around timestamps or other int64_t values. There
On Thu, Apr 30, 2020 at 5:21 PM James Almer wrote:
> On 4/30/2020 7:19 PM, Dale Curtis wrote:
> > Many places are using their own custom code for handling overflow
> > around timestamps or other int64_t values. There are enough of these
> > now that having some common saturated math functions see
On 4/30/2020 7:19 PM, Dale Curtis wrote:
> Many places are using their own custom code for handling overflow
> around timestamps or other int64_t values. There are enough of these
> now that having some common saturated math functions seems sound.
>
> This adds implementations that just use the bu
On 4/30/2020 8:20 PM, Carl Eugen Hoyos wrote:
> Am Fr., 1. Mai 2020 um 00:20 Uhr schrieb Dale Curtis
> :
>>
>> Many places are using their own custom code for handling overflow
>> around timestamps or other int64_t values. There are enough of these
>> now that having some common saturated math fun
Am Fr., 1. Mai 2020 um 00:20 Uhr schrieb Dale Curtis :
>
> Many places are using their own custom code for handling overflow
> around timestamps or other int64_t values. There are enough of these
> now that having some common saturated math functions seems sound.
> This adds implementations that j
Many places are using their own custom code for handling overflow
around timestamps or other int64_t values. There are enough of these
now that having some common saturated math functions seems sound.
This adds implementations that just use the builtin functions for
recent gcc, clang when availabl
29 matches
Mail list logo
