[FFmpeg-devel] [PATCH 11/11] Make ff_cmap_read_palette static to libavcodec/iff.c. Delete iff.h.

Ronald S. Bultje rsbultje
Wed Jan 26 18:00:13 CET 2011


On Wed, Jan 26, 2011 at 11:57 AM, Reinhard Tartler <siretart at tauware.de> wrote:
> On Mi, Jan 26, 2011 at 17:30:45 (CET), Ronald S. Bultje wrote:
>> Hi,
>> On Jan 26, 2011, at 10:50 AM, Reinhard Tartler <siretart at tauware.de> wrote:
>>> On Tue, Jan 25, 2011 at 03:52:10 (CET), Ronald S. Bultje wrote:
>>>> Hi,
>>>> 2011/1/24 M?ns Rullg?rd <mans at mansr.com>:
>>>>> "Ronald S. Bultje" <rsbultje at gmail.com> writes:
>>>>>> On Mon, Jan 24, 2011 at 8:29 PM, Diego Elio Petten? <flameeyes at gmail.com> wrote:
>>>>>>> The iff.h header only declared one function that is now static, the
>>>>>>> libavformat/iff.c source file wasn't using it before. Drop the file
>>>>>>> entirely.
>>>>>> I believe we're keeping this one for backwards compatibility. You can
>>>>>> put it under an #if VERSION...
>>>>> Compatibility with what? ?It's not a public interface.
>>> ACK
>>>> It was for Debian, so people can mix and match libavcodec/format
>>>> versions. Can the Debian maintainer please remind me why we kept it?
>>> What makes you think so? Since it is not a public header, no application
>>> is supposed to be able to reference it.
>>> There may be weird applications that reference the symbol
>>> ff_cmap_read_palette, but since Diego has an outstanding research on
>>> this issue, I trust him that this is not the case.
>> It's non-static b/c lavc iff video decoder used it, and we kept it
>> there for those poor souls mixing different lavc/f versions.
> the thing becomes complicated in case a major bump happens. in that case
> it can happen that the library that was not bumped is still on the disk,
> and applications that are linked to it still use it. In that case we'd
> need to keep it until the next major bump.
> I don't see that this is the case here. Am I overlooking something?

What if people don't upgrade their SVN/git every day? It could be that
people update from a specific point in time to a specific point in
time where the above bug does happen.

I'm not against removing the symbol, this is just what was brought up
a while ago as for why we kept the symbol...


More information about the ffmpeg-devel mailing list