On 01/12/2016 10:44 PM, Andreas Cadhalpun wrote:
Why are we using stdint types for non-vector data here? Our custom has
always been to used sized (stdint-style) data only for vector data (arrays
etc.), and use native-sized types (e.g. unsigned, int, whatever) for scalar
values. Why are we making
On 12.01.2016 03:26, Ronald S. Bultje wrote:
> On Mon, Jan 11, 2016 at 12:06 AM, Mats Peterson <
>> On 01/10/2016 11:56 AM, Andreas Cadhalpun wrote:
>>> --- a/libavformat/qtpalette.c
>>> +++ b/libavformat/qtpalette.c
>>> @@ -48,7 +48,7 @@ int ff_get_qtpalette(int codec_id, AVIOContext *pb,
>>> uint
On 01/12/2016 06:28 AM, Mats Peterson wrote:
Exactly, I actually thought of that myself. And I like the stdint
variables because they eliminate guesswork. That has always been a
problem with the "standard" types in C.
The stdint TYPES, of course.
Mats
__
On 01/12/2016 05:48 AM, Ganesh Ajjanagadde wrote:
You're free to make another patch, or if perhaps I should do it.
If something is inherently 32 bits (e.g obtained by reading 4 bytes),
then please don't make such a patch.
Seems to be the case here, and so I would nack such a patch:
color_start
On 01/12/2016 05:51 AM, Ganesh Ajjanagadde wrote:
On Mon, Jan 11, 2016 at 9:48 PM, Mats Peterson
wrote:
On 01/12/2016 03:32 AM, Mats Peterson wrote:
Don't blame yourself; it is in fact a regression IMHO to change to
unsigned int, albeit a theoretical one. C only guarantees 16 bits for
int/unsi
On Mon, Jan 11, 2016 at 9:48 PM, Mats Peterson
wrote:
> On 01/12/2016 03:32 AM, Mats Peterson wrote:
>>
>> Valid question. Of course there's no problem using uint32_t, but in the
>> original code the variables are unsigned int... ask Andreas ;)
>
>
> Well, I'm to blame as well, since I have been u
On Mon, Jan 11, 2016 at 9:35 PM, Mats Peterson
wrote:
> On 01/12/2016 03:32 AM, Mats Peterson wrote:
>>
>> On 01/12/2016 03:26 AM, Ronald S. Bultje wrote:
>>>
>>> Why are we using stdint types for non-vector data here? Our custom has
>>> always been to used sized (stdint-style) data only for vecto
On 01/12/2016 03:32 AM, Mats Peterson wrote:
Valid question. Of course there's no problem using uint32_t, but in the
original code the variables are unsigned int... ask Andreas ;)
Well, I'm to blame as well, since I have been using uint32_t for the a,
r, g and b variables rather than unsigned
On 01/12/2016 03:32 AM, Mats Peterson wrote:
On 01/12/2016 03:26 AM, Ronald S. Bultje wrote:
Why are we using stdint types for non-vector data here? Our custom has
always been to used sized (stdint-style) data only for vector data
(arrays
etc.), and use native-sized types (e.g. unsigned, int, wh
On 01/12/2016 03:26 AM, Ronald S. Bultje wrote:
Why are we using stdint types for non-vector data here? Our custom has
always been to used sized (stdint-style) data only for vector data (arrays
etc.), and use native-sized types (e.g. unsigned, int, whatever) for scalar
values. Why are we making e
Hi,
On Mon, Jan 11, 2016 at 12:06 AM, Mats Peterson <
matsp888-at-yahoo@ffmpeg.org> wrote:
> On 01/10/2016 11:56 AM, Andreas Cadhalpun wrote:
>
>> This fixes segmentation faults due to out of bounds writes, when
>> color_start is interpreted as negative number.
>>
>> This regression was intro
On 01/11/2016 11:18 PM, Andreas Cadhalpun wrote:
It can probably also happen with matroska files, but I saw it crash with
a mov file.
In any case, I pushed the patch now.
Best regards,
Andreas
OK on the mov file, and thx for the push.
Mats
___
ff
On 10.01.2016 13:03, Mats Peterson wrote:
> On 01/10/2016 11:56 AM, Andreas Cadhalpun wrote:
>> This fixes segmentation faults due to out of bounds writes, when
>> color_start is interpreted as negative number.
>>
> Yes Andreas, until my normalization patch for matroskadec.c is applied, of
> cours
On 01/10/2016 11:56 AM, Andreas Cadhalpun wrote:
This fixes segmentation faults due to out of bounds writes, when
color_start is interpreted as negative number.
This regression was introduced in commit 57631f.
Signed-off-by: Andreas Cadhalpun
---
Seriously, changing the code behavior when "fa
On 01/10/2016 01:03 PM, Mats Peterson wrote:
dYes Anreas, until my normalization patch for matroskadec.c is applied,
of course it's very easy for these variables to be negative when using
an int, because of the invalid private data. I stand corrected.
Sorry, ANDREAS. This Thunderbird is killing
On 01/10/2016 11:56 AM, Andreas Cadhalpun wrote:
This fixes segmentation faults due to out of bounds writes, when
color_start is interpreted as negative number.
dYes Anreas, until my normalization patch for matroskadec.c is applied,
of course it's very easy for these variables to be negative wh
On 01/10/2016 12:29 PM, Mats Peterson wrote:
Good advice to a hysterical person like me. Thanks.
At least I'm able to admit that I've been wrong, unlike some other
people (no names mentioned).
Mats
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.o
On 01/10/2016 12:29 PM, Andreas Cadhalpun wrote:
Just take the 5 minutes to check the facts before sending
the first reply.
Best regards,
Andreas
Good advice to a hysterical person like me. Thanks.
Mats
___
ffmpeg-devel mailing list
ffmpeg-devel@ff
On 10.01.2016 12:24, Mats Peterson wrote:
> On 01/10/2016 12:23 PM, Andreas Cadhalpun wrote:
>
>> Please check the facts before writing a reply. Thanks.
>
> It's human to err;) Thanks, anyway.
But it's bad style to send two mails contradicting each other
within 5 minutes.
Just take the 5 minute
On 01/10/2016 12:23 PM, Andreas Cadhalpun wrote:
Please check the facts before writing a reply. Thanks.
It's human to err;) Thanks, anyway.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 10.01.2016 12:17, Mats Peterson wrote:
> On 01/10/2016 12:14 PM, Mats Peterson wrote:
>> On 01/10/2016 12:13 PM, Mats Peterson wrote:
>>> As far as I remember, those variables were ints in the original code in
>>> mov.c, and they will hardly reach a value where they could be
>>> interpreted as i
On 10.01.2016 12:13, Mats Peterson wrote:
> On 01/10/2016 11:56 AM, Andreas Cadhalpun wrote:
>> This fixes segmentation faults due to out of bounds writes, when
>> color_start is interpreted as negative number.
>>
>> This regression was introduced in commit 57631f.
>>
>> Signed-off-by: Andreas Cadh
On 01/10/2016 12:14 PM, Mats Peterson wrote:
On 01/10/2016 12:13 PM, Mats Peterson wrote:
As far as I remember, those variables were ints in the original code in
mov.c, and they will hardly reach a value where they could be
interpreted as ints. But it's of course better to be on the safe side.
T
On 01/10/2016 12:13 PM, Mats Peterson wrote:
As far as I remember, those variables were ints in the original code in
mov.c, and they will hardly reach a value where they could be
interpreted as ints. But it's of course better to be on the safe side.
Thanks for the heads-up.
Interpreted as negati
On 01/10/2016 11:56 AM, Andreas Cadhalpun wrote:
This fixes segmentation faults due to out of bounds writes, when
color_start is interpreted as negative number.
This regression was introduced in commit 57631f.
Signed-off-by: Andreas Cadhalpun
---
Seriously, changing the code behavior when "fa
25 matches
Mail list logo
