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-requ...@ffmpeg.org with subject "unsubscribe".
