Re: [FFmpeg-devel] [RFC] Advanced Error Codes

[Nicolas George <george@nsup.org>]

Michael Niedermayer (HE12025-07-03):
> return av_adv_err_new(AVERROR_INVALIDDATA, "Garbled foobar data", "Foo triangle quantum decoder"
>                       __FILE__, __LINE__, NULL, "Whaetver you like %s", favorite_food);
> 
> teh return type is int64_t here

So we need to change all our return types?

> this also cannot fail as it allocates nothing

Where does the memory storing “favorite_food” come from?

> it also needs no context but would use a mutex or thread local storage
> 
> the message length would be bound by a maximum,

Of course.

> I am not sure if passing a context around is going to find the volunteers
> to implement and maintain. Also it has a performance impact for small and
> lightweight functions.

We already pass contexts around everywhere.

I would argue that the small lightweight functions that do not already
have a context for the error are too low level to be able to provide a
meaningful error message.

So, my proposal is similar to yours, except for the following
differences:

- We allocate the memory for error messages contexts. That way, we avoid
  the issue of using locks or thread-local storage but do not have a
  hard limit on simultaneous errors.

- We do not change the return type of all our API, we still return “a
  negative AVERROR code” to keep source compatibility, and use the best
  code we can find.

- If there is no context, we stick with error codes. AVERROR(EINVAL) is
  enough to say that RGB27 does not exist. A function with a context
  calling a function without a context is responsible for turning the
  error code into a meaningful message by including contextual
  information.

Regards,

-- 
  Nicolas George
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".