GCC 3.4 introduced an attribute warn_unused_result to warn when a programmer
discards the return value. Applying this judiciously across the codebase can help
in fixing a lot of problems. At a high level, functions which return error codes
should always be checked. More concretely, consider the functions ff_add_format
and the like in avfilter/formats.h. A quick examination shows that a large portion
of libavfilter fails to handle the associated errors, usually AVERROR(ENOMEM).
The above example was where I observed the utility of this, but it should be
useful in many places across the code base.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Prior to this on msvc/icl there was no handling of deprecated functions
and the deprecated warning was disabled.
After enabling there are a number of warnings relating to the CRT and
the use of the non-secure versions of several functions. Defining
_CRT_SECURE_NO_WARNINGS silences these warnings.
Signed-off-by: Martin Storsjö <martin@martin.st>
This silence bunch of useless warnings like:
libavformat/mpeg.c:393:37: warning: variable 'dvdaudio_substream_type' is uninitialized when used within its own initialization [-Wuninitialized]
Signed-off-by: Paul B Mahol <onemda@gmail.com>
as it breaks ICC:
libavcodec/libavcodec.a(snowenc.o): In function `encode_q_branch':
/home/fate/x86_64-linux-gnu-icc-2011.4.191/src/libavcodec/snowenc.c:405: undefined reference to `ff_epzs_motion_search'
/home/fate/x86_64-linux-gnu-icc-2011.4.191/src/libavcodec/snowenc.c:414: undefined reference to `ff_get_mb_score'
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
With unknown attribute warnings disabled, these checks are no
longer needed. Removing them improves readability while having
no effect on generated code.
Signed-off-by: Mans Rullgard <mans@mansr.com>
also attributes.h is public and external api and can thus not depend
on configure tested compiler support thus this part is removed. A
different solution must be found if this breaks for some compiler
which i hope it does not.
Originally committed as revision 23115 to svn://svn.ffmpeg.org/ffmpeg/trunk
Passing an explicit filename to this command is only necessary if the
documentation in the @file block refers to a file different from the
one the block resides in.
Originally committed as revision 22921 to svn://svn.ffmpeg.org/ffmpeg/trunk
Ganesh Ajjanagadde
James Almer
Michael Niedermayer
Vittorio Giovara
Alex Smith
Kirill Gavrilov
Paul B Mahol
Reinhard Tartler
Ronald S. Bultje
J. Bohl
Nicolas George
Martin Storsjö
Mans Rullgard
Carl Eugen Hoyos
Carl Eugen Hoyos
Diego Biurrun