[FFmpeg-cvslog] r19787 - in trunk/libavcodec: aac.c aacenc.c ac3enc.c adpcm.c adxenc.c flacenc.c g726.c libfaac.c libgsm.c libmp3lame.c libopencore-amr.c libvorbis.c mpegaudioenc.c pcm-mpeg.c pcm.c roqaudioenc.c v...

[Måns Rullgård]

Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:

> On Sun, Sep 06, 2009 at 03:11:56PM +0200, Diego Biurrun wrote:
>> On Sun, Sep 06, 2009 at 11:25:06AM +0200, Reimar D?ffinger wrote:
>> > While I think it is still a good change, it may have been a bit silly,
>> > since gcc still seems to be unable to place those compound literals in
>> > .rodata, they still end up in data (a quick search indicates this was
>> > first reported against gcc 3.0.3 and nobody cared...).
>> 
>> There's always hope for better compilers...
>
> You gave me an idea, and indeed 64 bit icc 11 does put it into .rodata
> now but not before this change.
> So since there is a benefit I might continue these kind of changes e.g.
> for pix_fmts, complain ASAP if you object or want to see a patch first.

Adding const where it should be is always a good thing, even if the
compiler doesn't do anything with it.

> Apart from that, I am very unhappy about the way decoders, encoders,
> muxers etc. get registered currently, only due to the "next" pointer all
> of that has to stay in the .data section and making up about 100 kB and
> constantly growing...

Do you have a suggestion for a portable alternative?

-- 
M?ns Rullg?rd
mans at mansr.com