Some possibly useful very old WIP commits of mine

[rowanthorpe]

After the changes I had submitted pre-github, I was working on a few other things intending to submit some PRs here about 2 years ago, then life really got in the way and that branch just stagnated locally. I rediscovered it now when searching for something else, and when I looked I realized I probably won't have the time to get back the mental context to know what to do with it, and in some cases even to know what I was intending. As more time passes that becomes even more likely.

So in an attempt to make at least some of that work useful, I rebased the WIP commits on latest master branch, resolving merge-conflicts as logically as could be quickly apparent, and am opening this issue for you to have a quick look at the latest 3 commits there when you have time (as you will still have the mental context to perhaps find some of it useful, with a little extra work). Of course I am not opening a PR because none of it is PR-worthy, or even finished. Whenever you've had a look and found any of it useful/useless/whatever, please feel free to close this issue.

It is noteworthy that a few of the commits since sflowtool moved to github have implemented what my original WIP included, so rebasing actually shrunk my changes considerably [sigh].

[sflow]

Rowan, Sorry for the long delay...

(1) I checked in changes to allow the NetFlow export to be over IPv6, although that has the effect of disabling the source spoofing so it will probably not be widely used.

(2) I don't get the my_exit() thing. A regular exit() will free all the memory and close all the sockets. Why add code for this?

(3) I also checked in changes to use _WIN32 instead of WIN32. However I wasn't sure about the value/correctness of using int32_t as a type for SOCKET. It always seemed OK to use int and let -1 plainly represent INVALID_SOCKET. Do the compilers on Windows complain? I almost never compile on Windows and would consider dropping support for it now that it is getting easier to run sflowtool in a Docker container. Do you think we could get away with that?

Let me know if I missed anything else. And apologies if rebasing is painful.

Neil

[sflow]

We dropped support for Windows (can always run sflowtool as a Docker container instead), so I'm going to close this issue now. Please come back again if I missed something.