I wouldn't put all gitignore files as part of this PR, when you want to add that, make that a separate PR. Also by using the C++ uniform initialization, std::unique_ptr, std instead of ACE_OS this could be more modern C++.

I haven't looked at the issue in detail, this probably needs some detailed review, also the fact that you mention that your approach is maybe not the best will trigger review

I wouldn't put all gitignore files as part of this PR, when you want to add that, make that a separate PR.

Done in #2133. The changes will disappear from here when that's merged and this is rebased.

Also by using the C++ uniform initialization, std::unique_ptr, std instead of ACE_OS this could be more modern C++.

Do you have specific callouts? I actually took pains to use the same techniques, tools, and styles used elsewhere in the code that I was changing, because it was not clear to me which things (like unique_ptr) were and were not allowed, or even which C++ standard (C++11, C++17, etc.) this master is targeting.

I haven't looked at the issue in detail, this probably needs some detailed review, also the fact that you mention that your approach is maybe not the best will trigger review

I certainly welcome the review. I came up with the best solution that I knew how to, but I do not know this code nearly as well as do you, and it's possible that you just want to do it a different way, or maybe you'll even do a complete refactor of the affected areas to achieve other goals I'm not aware of.

I resolved the Fuzz issues, and I worked through all the Codacy issues that I thought were valid. Two of them are clearly false positives caused by the use of the ACE_ERROR_RETURN macro. The other is, I believe, also a false positive, but it may go away based on resolution of my question above ("Do you have specific callouts?"), i.e. I may made this a std::string instead of a char *. I'm torn on the CodeFactor issues, because they are indeed complex methods, but they were already complex methods, and there are even-more complex methods in that file. Refactoring them to be less-complex (splitting into multiple methods) might not be worth the effort.

I'm waiting on platform-specific build results now.

Should "ORBListener" by replaced by "ORBListen"? See TAO/docs/ORBEndpoint.html for established usage.

Master requires c++14 or newer

New test should be added to bin/lst file

New test should be added to bin/lst file

I can't find a file named lst, so this must be short for something I don't understand. Could you elaborate?

I just found TAO/bin/tao_other_tests.lst. I'll add it there.

I've rebased to remove all the unrelated .gitignore additions, and responded to the above comments with several refactors. The two remaining Codacy issues are clear false positives. The CodeFactor issues are a subjective matter of opinion that I welcome feedback on. I can provide additional refactorings to simplify these functions/methods, but I'm worried about the scope creeping too much on this change. I think it's good to merge as-is, but will proceed however requested.

One thing I did notice through all of this work is that there are about half a dozen different places that use getifaddrs and/or GetAdaptersAddresses to go through interfaces and addresses, and many of them have the same if windows do this else do that macro logic. A major refactor that could be a benefit would be to extract this into a set of platform-generic C++11-modern helper classes, which would simplify many functions/methods, including the two mentioned by CodeFactor. However, that would touch a lot of major areas in excess of the minimum areas needed to fix this issue, so I'm not comfortable proceeding with that without some kind of prior approval.

Please open a new issue for the getifaddrs/GetAdaptersAddresses proposal, that way it doesn't get lost.