Re: [FFmpeg-devel] [PATCH 4/6] doc/developer: add a code behaviour section to development policy

[Andreas Rheinhardt <andreas.rheinhardt@outlook.com>]

Anton Khirnov:
> Document our longstanding de facto policies on things like correctness,
> thread-safety, UB, etc.
> ---
>  doc/developer.texi | 50 +++++++++++++++++++++++++++++++++-------------
>  1 file changed, 36 insertions(+), 14 deletions(-)
> 
> diff --git a/doc/developer.texi b/doc/developer.texi
> index df43119f98..afa0148137 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -274,10 +274,6 @@ symbols. If in doubt, just avoid names starting with @code{_} altogether.
>  @section Miscellaneous conventions
>  
>  @itemize @bullet
> -@item
> -fprintf and printf are forbidden in libavformat and libavcodec,
> -please use av_log() instead.
> -
>  @item
>  Casts should be used only when necessary. Unneeded parentheses
>  should also be avoided if they don't make the code easier to understand.
> @@ -286,6 +282,42 @@ should also be avoided if they don't make the code easier to understand.
>  @anchor{Development Policy}
>  @chapter Development Policy
>  
> +@section Code behaviour
> +
> +@subheading Correctness
> +The code must be valid. It must not crash, abort, access invalid pointers, leak
> +memory, cause data races or signed integer overflow, or otherwise invoke
> +undefined behaviour. Error codes should be checked and, when applicable,
> +forwarded to the caller.
> +
> +@subheading Thread- and library-safety
> +Our libraries may be called by multiple independent callers in the same process.
> +These calls may happen from any number of threads and the different call sites
> +may not be aware of each other - e.g. a user program may be calling us directly,
> +and use one or more libraries that also call us. The code must behave correctly
> +under such conditions.

Some of this can no longer be guaranteed when FFmpeg is built without
threading support, but called from multiple threads concurrently. Should
this be mentioned or would it just confuse readers? (I'm leaning to the
latter.)

- Andreas

_______________________________________________
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".