Add basic logic for g_socket

[NoobsEnslaver]

Hi, it's needed for ability to share socket between udpsrc and udpsink - it is common case for NAT traversal

[RSWilli]

These tiny changes prevent very hard to debug memory errors

[RSWilli]

It looks like you have to add some build flags to prevent building the GSocket on Windows, so that Windows users can still use the library.

[NoobsEnslaver]

It looks like you have to add some build flags to prevent building the GSocket on Windows, so that Windows users can still use the library.

let try to fix it with generics.
Problem in that - syscall.Socket returns int in *nix systems, but syscall.Handle -> uintptr -> uint in windows. uint and int - both int and looks like this generic may fix it, but i can't check it local or run pipeline

[RSWilli]

You could also handle it like the golangs syscall package itself handles the multiple systems: https://cs.opensource.google/go/go/+/refs/tags/go1.22.2:src/syscall/syscall_linux.go;l=1207. If you cannot test it in Windows I would be okay with it if you only provide an implementation for Linux (and MacOS, which already works), and leave the further implementation to someone that can test it. I myself cannot test it either, I fully rely on the GitHub pipeline.

[NoobsEnslaver]

run pipeline plz, let check windows build. I can't run myself without approval

I think the example you gave will not work because in our case there are no two different functions to call, it is one, but with different types of argument depending on which file will participate in the build. Perhaps we can do without generics by explicitly converting the type to int - this will be ok for windows (uintptr -> int), and will be a truism for linux (int -> int), which may cause warnings, but it's still ok

[RSWilli]

I think the example you gave will not work because in our case there are no two different functions to call

My proposal was rather: don't provide an implementation for windows. If an implementation for windows is desired, then the function could also have completely different arguments, no need to provide an abstraction to unify the different systems

[RSWilli]

It seems to work now in our pipeline. Can you add some docs, please? The I would be happy to merge

[RSWilli]

@NoobsEnslaver Thanks for your contribution