On Fri, Dec 30, 2016 at 10:32:46AM +0100, wm4 wrote: > On Wed, 28 Dec 2016 17:34:33 +0100 > "Diego Biurrun" <di...@biurrun.de> wrote: > > On Wed, Dec 28, 2016 at 07:47:58AM +0100, Luca Barbato wrote: > > > On 27/12/2016 19:31, Anton Khirnov wrote: > > > > Extend the width/height doy to clarify that it should store coded > > > > values. > > > > --- > > > > doc/APIchanges | 4 ++++ > > > > libavutil/frame.c | 4 ++++ > > > > libavutil/frame.h | 28 +++++++++++++++++++++++++++- > > > > libavutil/version.h | 2 +- > > > > 4 files changed, 36 insertions(+), 2 deletions(-) > > > > > > size_t, while correct, feels out of place somehow. > > > > > > Ok if we really plan to move to size_t everywhere else. > > > > I'm all for moving in the direction of size_t. See my patch that > > changes parts of the crypto API to use size_t. > > While I agree that it'd be a good idea to use size_t instead of int > for these things, creating an inconsistency is also a PITA. Other new > API also uses int, so why size_t just for those new fields?
That new API needs to be changed in the direction of size_t then. Examples of new API using int welcome.. Diego _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
