Build Fix.

[jlsantiago0]

bool ParseFilterConfig() 3 parameter version is called in srtcore/socketconfig.h:1072, but there is no prototype defined for it. This causes build failures with toolchains that do not auto-create an int ParseFilterConfig() for calls to undefined functions. This could also cause ABI issues if sizeof(bool) != sizeof(int) causing potential memory access violations.

[ethouris]

BTW. Might be a good idea to mention what exactly toolchains fail to compile this. It's because someone in future might simply remove this definition as being repeated after the friend definition of the same function inside the class and cause the build failure again.

[jlsantiago0]

BTW. Might be a good idea to mention what exactly toolchains fail to compile this. It's because someone in future might simply remove this definition as being repeated after the friend definition of the same function inside the class and cause the build failure again.

The makitoX toolchain for 1. And a couple of others that I was building for.

[maxsharabayko]

I would say some refactoring is better to be done here. 🤔
I am not addressing this to you, @jlsantiago0. Just saving my thoughts for later to see if some time could be spent here or we should just proceed with this fix and put the rest to the technical debt.

A fair comment by @quink-black that this code should better be placed under srt namespace is also worth addressing. Issue #1924 generalizes this point.

Possible Refactoring

One way I see is to change the ParseFilterConfig function to return a pointer to void instead of bool. A NULL returned would mean false, otherwise, a pointer to an existing PacketFilter::Factory is returned.

void* ParseFilterConfig(std::string s, SrtFilterConfig& w_config);

Way number two: move the abstract class PacketFilter::Factory into packet_filter_api.h. Of course, place everything under the srt namespace.
Then refine the declaration that already exists in packet_filter_api.h:

bool ParseFilterConfig(std::string s, SrtFilterConfig& w_config);

[jlsantiago0]

@maxsharabayko Well the current one line change fixes the build. That should be merged and then the cleanup/refactor would be a different issue to be addressed later.