[FFmpeg-devel] [PATCH] Explicitely declare {dst, src}Format sws_get*Context() params as enum PixelFormat

[Stefano Sabatini]

On date Thursday 2009-02-12 00:37:17 +0100, Michael Niedermayer encoded:
> On Wed, Feb 11, 2009 at 10:28:05PM +0100, Stefano Sabatini wrote:
> > On date Tuesday 2009-02-10 01:57:36 +0100, Michael Niedermayer encoded:
> > > On Tue, Feb 10, 2009 at 12:04:11AM +0100, Stefano Sabatini wrote:
> > > > On date Monday 2009-02-09 19:22:23 +0100, Michael Niedermayer encoded:
> > > > > On Mon, Feb 09, 2009 at 06:10:41PM +0100, Stefano Sabatini wrote:
> > > > > > On date Monday 2009-02-09 17:55:29 +0100, Diego Biurrun encoded:
> > > > > > > On Mon, Feb 09, 2009 at 05:48:46PM +0100, Stefano Sabatini wrote:
> > > > > > > > On date Monday 2009-02-09 09:27:35 +0100, Stefano Sabatini encoded:
> > > > > > > > > On date Sunday 2009-02-08 21:48:25 -0800, Art Clarke encoded:
> > > > > > > > > > On Sun, Feb 8, 2009 at 3:00 PM, Stefano Sabatini
> > > > > > > > > > <stefano.sabatini-lala at poste.it> wrote:
> > > > > > > > > > >> I wonder if I should bump micro/minor, maybe there are some
> > > > > > > > > > >> compatibility issues with some compilers...
> > > > > > > > > > >
> > > > > > > > > > > Applied.
> > > > > > > > > > 
> > > > > > > > > > A little late now, but you should at least bump minor;  This breaks
> > > > > > > > > > code for swscale users who previously passed in int values (like, oh,
> > > > > > > > > > us).
> > > > > > > > > > 
> > > > > > > > > > We ran into the problem because we wanted to disguise the PixelFormat
> > > > > > > > > > dependency in other objects and hence pass-around an opaque int; we
> > > > > > > > > > just didn't cast it when passing back into SWSContext calls because we
> > > > > > > > > > didn't have to (until this morning when our builds started breaking).
> > > > > > > > > > 
> > > > > > > > > > It's a simple fix in users' code, but I think it is an API change
> > > > > > > > > > (yes, for the better, but a change none the less).
> > > > > > > > > 
> > > > > > > > > So we maybe should revert it, since it breaks compatibility. If
> > > > > > > > > someone care feel free to do it, then I'll provide a backward
> > > > > > > > > compatible change (#if version < ...) this night.
> > > > > > > > 
> > > > > > > > OK to revert or there are better ideas?
> > > > > > > 
> > > > > > > If Art can live with the version bump I think reverting is not necessary.
> > > > > > 
> > > > > > It's not only Art, all other users could update and get compilation
> > > > > > broken.
> > > > > 
> > > > > so if i configure gcc to error out on a comment that contains "teh"
> > > > > then we will consider adding such typo requireing a bump?
> > > > 
> > > > Uh? Sorry my zen is a little rusty ;-).
> > > > 
> > > > Do you mean that it was a bug in the first place, so using int rather
> > > > than enum PixelFormat is/was to be considered an user error?
> > > 
> > > iam saying that it should work fine with int and enum and its the users
> > > odd things that he did (using a private enum?) that broke it
> > 
> > Art explained the scenario when such a change caused a breakage, well
> > they indeed did a rather dangerous thing and I consider after all the
> > definition/declaration discrepancy we had before a bug on our side.
> > 
> > >From the technical point of view we may consider it:
> > 1) a non-backward compatible change, thus requiring a major bump
> > 
> > 2) a bug fix on our side which fixed a previously (mildly) broken API,
> > in this case it should be safe to just bump micro.
> > 
> > Minor bumps should be performed when introducing new symbols, for
> > example introducing a sws_getContext2(), which would be totally
> > screaming overkill for such a scenario.
> > 
> > I think everyone would agree that choice 1) is plain overkill as well,
> > while I think 2) is quite tolerable.
> > 
> > So I propose these two choices to the maintainer, which are:
> > 
> > 1) bump micro
> 
> ok

Applied.
-- 
FFmpeg = Fantastic and Faithful Merciless Picky Easy God