On Fri, May 26, 2017 at 03:12:43PM +0300, Martin Storsjö wrote: > On Fri, 26 May 2017, Diego Biurrun wrote: > >--- > >TLS is not handled like other protocols. Instead the implementation details > >of which crypto library is used get exposed to the user. Hiding those > >details allows simplifying and refactoring some code and avoiding the > >special-casing of TLS. > > > >This should get a slightly more elaborate log message before pushing. > > > >configure | 8 ++---- > >libavformat/Makefile | 3 +- > >libavformat/network.c | 20 -------------- > >libavformat/protocols.c | 3 +- > >libavformat/tls.c | 70 > >+++++++++++++++++++++++++++++++++++++++++------ > >libavformat/tls.h | 8 ------ > >libavformat/tls_gnutls.c | 53 +++-------------------------------- > >libavformat/tls_openssl.c | 53 +++-------------------------------- > >libavformat/utils.c | 4 +++ > >9 files changed, 77 insertions(+), 145 deletions(-) > > Doesn't this partially revert parts of what was done in > d8ffb2055f0e0fcb5d025bab72eb19c2a886c125? While I was the one who originally > wrote in the way it was with all of the gnutls and openssl implementations > all in tls.c, I don't want this code to be moving back and forth, and I now > enjoy the clarity of having them cleanly separated.
It partially does revert the commit now that I have looked at it, but I don't really see a problem. The lib-specific code remains in separate files, just the shared bits are refactored and the ff_tls_foo --> ff_tls_gnutls_foo indirections are avoided... Does the '#include "tls_gnutls.c"' anger your taste buds? Diego _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
