On 4/21/2017 7:05 AM, Diego Biurrun wrote:
On Fri, Apr 21, 2017 at 07:06:04AM +0200, wm4 wrote:
On Thu, 20 Apr 2017 11:26:10 -0400
Vittorio Giovara <[email protected]> wrote:
This should make these APIs simpler to use, and less error prone
in case the caller does not check they are valid, and makes them
more similar to other naming APIs.
---
This should help in the bug in avprobe found by Luca.
Sending as RFC since I believe we are allowed to break this API as we
did the version bump, but I'd like to be sure.
libavutil/pixdesc.c | 10 +++++-----
libavutil/pixdesc.h | 10 +++++-----
2 files changed, 10 insertions(+), 10 deletions(-)
This is a serious API change and needs to go through the entire
deprecation circus.
We're still in the bump period...
Diego
That gives you free reign to play with offsets in public structs and
with symbol availability, but not to change the signature or return
value of functions in a way that existing downstream code will break.
API breaks are not the same as ABI breaks.
As a library user i expect av_color_space_name() to return NULL when
it's feed an out of range AVCOL_SPC_ value. This patchset will make code
like
if (!av_color_space_name(somevalue)) return EINVAL;
never return on out of range values, thus it's an API break. Regardless
of me linking my program with libavutil 54, 55 or 56, the behavior
should be the same.
Changing a -1 return value to AVERROR() is "acceptable" since a < 0
check would work on both, although still technically not a very nice
thing to do. But if you want to change NULL into "unknown", then a
different function with a different signature needs to be introduced.
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
