Quoting Alexandra Hájková (2015-08-04 12:46:27)
The length of BOOL values is 16 bits in the Metadata Object but
32 bits in the Extended Content Description Object.
---
libavformat/asfdec.c | 52
1 file changed, 36 insertions(+), 16
On 11/08/15 10:15, Anton Khirnov wrote:
Quoting Luca Barbato (2015-08-03 22:51:52)
The resulting mapped array is used as non-const.
Again, no -- the function does not modify buf.
Shall we drop that warning for those specific functions then? The
compiler triggers quite often and it is just
Quoting Luca Barbato (2015-08-03 22:51:51)
The actual mapped array is going to be written.
No it's not?
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Quoting Luca Barbato (2015-08-03 22:51:50)
The resulting mapped array is used as non-const.
---
libavutil/samplefmt.c | 2 +-
libavutil/samplefmt.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavutil/samplefmt.c b/libavutil/samplefmt.c
index bff6004..453ba4c
Quoting Luca Barbato (2015-08-03 22:51:52)
The resulting mapped array is used as non-const.
Again, no -- the function does not modify buf.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
On Tue, 11 Aug 2015, Anton Khirnov wrote:
Quoting Luca Barbato (2015-08-03 22:51:50)
The resulting mapped array is used as non-const.
---
libavutil/samplefmt.c | 2 +-
libavutil/samplefmt.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavutil/samplefmt.c
Quoting Andreas Cadhalpun (2015-08-08 13:37:08)
They are still widely used and have been deprecated for less than two years.
Signed-off-by: Andreas Cadhalpun andreas.cadhal...@googlemail.com
---
libavcodec/avcodec.h | 2 +-
libavcodec/utils.c | 2 +-
libavcodec/version.h | 3 +++
3
Quoting Henrik Gramner (2015-08-01 17:27:38)
---
libavutil/x86/x86inc.asm | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm
index d70a5f9..0e2f447 100644
--- a/libavutil/x86/x86inc.asm
+++
Quoting Luca Barbato (2015-08-03 22:51:48)
And fix the callers accordingly.
Address 1 clang warning.
---
libavcodec/vorbis_parser.c | 2 +-
libavcodec/vorbisdec.c | 2 +-
libavcodec/vp3.c | 2 +-
libavcodec/xiph.c | 4 ++--
libavcodec/xiph.h | 4 ++--
On 11/08/15 10:12, Anton Khirnov wrote:
Quoting Luca Barbato (2015-08-03 22:51:48)
And fix the callers accordingly.
Address 1 clang warning.
---
libavcodec/vorbis_parser.c | 2 +-
libavcodec/vorbisdec.c | 2 +-
libavcodec/vp3.c | 2 +-
libavcodec/xiph.c | 4
Hi,
I have gone retesting the open bugs from 100 to 200. I have retested the
samples provided for the following bugs.
These is what I have achieved.
108 abort() triggered in ff_find_unused_picture() Impossible to retest,
missing file
112 Invalid reads at dsicinav.c Retested
113
---
libavutil/x86/x86inc.asm | 32 +---
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm
index a519fd5..6ad9785 100644
--- a/libavutil/x86/x86inc.asm
+++ b/libavutil/x86/x86inc.asm
@@ -1,7 +1,7 @@
On 11.08.2015 11:34, Anton Khirnov wrote:
This API is dangerous -- it manipulates AVFrame internals from
libavcodec, even though AVFrame now lives in libavutil. It can break
badly if AVFrame is extended in libavutil, but libavcodec is not
updated. I think it also leaks side data, which cannot
13 matches
Mail list logo
