[FFmpeg-soc] AAC decoder compilation warnings

[Michael Niedermayer]

On Sat, Aug 02, 2008 at 05:43:05PM +0100, Robert Swain wrote:
> Hello,
> 
> It seems compiler warnings that could probably be ignored should be
> silenced as long as it does not obfuscate or slow down the code. The
> current warnings in the AAC decoder are:
> 
> libavcodec/aac.c: In function 'decode_ics':
> libavcodec/aac.c:1020: warning: passing argument 6 of
> 'decode_scalefactors' from incompatible pointer type
> libavcodec/aac.c:1020: warning: passing argument 7 of
> 'decode_scalefactors' from incompatible pointer type
> libavcodec/aac.c:1045: warning: passing argument 4 of
> 'decode_spectrum' from incompatible pointer type
> libavcodec/aac.c:1049: warning: passing argument 4 of 'dequant' from
> incompatible pointer type
> libavcodec/aac.c:1049: warning: passing argument 5 of 'dequant' from
> incompatible pointer type
> libavcodec/aac.c: In function 'mixdown_and_convert_to_int16':
> libavcodec/aac.c:1862: warning: passing argument 2 of
> 'ac->dsp.float_to_int16_interleave' from incompatible pointer type
> libavcodec/aac.c: In function 'decode_ics':
> libavcodec/aac.c:1005: warning: 'pulse.num_pulse' may be used
> uninitialized in this function
> libavcodec/aac.c:1005: warning: 'pulse.start' may be used
> uninitialized in this function
> 
> The first bunch in decode_ics() are all non-const arrays (band_type,
> band_type_run_end and sf) that are being passed into function
> arguments that have been declared as being const arrays. Two options
> are apparent: cast to const when passing the argument or remove the
> const qualifier from the function argument declaration. The latter
> would seem the better choice as long as it has no effect on potential
> optimisations within the functions in question. Would it have any
> adverse effects?

unlikely with gcc
feel free to remove consts in function declarations if the warnings bother
you.


> 
> float_to_int16_interleave is because the second argument is float
> *output_data[] while the function expects const float ** so again it's
> because of a const qualifier. It should be safe to cast to const float
> ** should it not?

it should be safe

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/attachments/20080802/c0f5f4aa/attachment.pgp>