[FFmpeg-devel] [FFmpeg-cvslog] Merge commit '94a417acc05cc5151b473abc0bf51fad26f8c5a0'

Nicolas George george at nsup.org
Sat Jan 4 12:00:19 CET 2014


Le quintidi 15 nivôse, an CCXXII, Michael Niedermayer a écrit :
> Merge commit '94a417acc05cc5151b473abc0bf51fad26f8c5a0'
> 
> * commit '94a417acc05cc5151b473abc0bf51fad26f8c5a0':
>   mathematics: remove asserts from av_rescale_rnd()
> 
> Conflicts:
> 	libavutil/mathematics.c
> 
> The asserts are left in place for now as no code checks the return
> value, but we sure can change this if application developers
> prefer

I am glad you did not merge it. IMHO, the asserts are exactly the correct
way of dealing with this kind of case, where there is obviously a mistake in
the calling code, especially when there are no other failure case: they
allow to spot the mistake immediately.

The rest of this message is rant about error reporting, you can safely
ignore it.

I see roughly three kind of error that a function may want to report:

1. Errors that the caller could have detected by implementing a trivial
   check or using the correct named constants. For example: using the wrong
   mode for seek(); taking the square root of a negative number; giving NULL
   for something that will be dereferenced.

   These errors I call "invalid use of the API".

   They correspond to bugs in the calling code. They may not be easy to fix
   (if something that should be positive is mysteriously negative, it may be
   hard to track down), but they should be fixed.

2. Errors that the caller had no way of predicting. For example: connecting
   to a closed port; I/O error reading from a file; out of memory.

   These errors I call "environmental errors".

3. Intermediate case: errors that the caller could predict but not reliably
   (e.g. a new version of the library could support more cases or be more
   strict) or not simply (e.g. by reimplementing a significant part of the
   library). For example: giving a corrupted byte stream to a decoder;
   giving a string in ISO-8859-1 to a function that expects UTF-8.

For case #2, "environmental errors", there is no solution except to use a
real error-reporting mechanism. In C, that means mostly an error code and
possibly a more detailed user-readable message. In other higher-level
languages, it may involve exceptions, but that is of no concern for FFmpeg.

For case #1, "invalid use of the API", I believe asserts or similar hard
failure with core dump are the best way: the application crashes immediately
when it is being developed, the developer has a backtrace and can fix the
invalid use of the API directly.

For case #3, the answer is less obvious, but mostly it will need to be
handled like an environmental error.


This particular patch cover clearly an "invalid use of the API".

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140104/80857de1/attachment.asc>


More information about the ffmpeg-devel mailing list