Quoting Andreas Rheinhardt (2023-08-26 20:36:25)
> 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.)
I tend to agree, it's a very obscure use case anyway.
But we should probably document more explicitly somewhere (and warn in
configure) what building without threads actually implies.
--
Anton Khirnov
_______________________________________________
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".
