Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't define SOCKET ourselves. #1261

Conversation

guyharris
Copy link
Member

@guyharris guyharris commented Jan 26, 2024

Doing so can cause namespace collisions, as per, for example, firnsy/barnyard2#245.

Instead, define PCAP_SOCKET, and use that.

On Windows, this shouldn't break any APIs, as any code using the two active-mode APIs that return a socket handle would probably be assigning their return values to a SOCKET, and as, on Windows, we're defining PCAP_SOCKET as SOCKET, there would be no type clash.

On UN*Xes, this might break code that uses one of the two active-mode APIs that return a socket handle if those programs were written to assign the return values of those APIs to a SOCKET, as we're no longer defining SOCKET. However, as those APIs are only provided if libpcap is built with remote capture support - which is not the default - and as they're somewhat painful to use, there's probably little if any code that needs to compile for UN*X and that uses them. If there is any such code, it could do

#ifndef PCAP_SOCKET
    #ifdef _WIN32
        #define PCAP_SOCKET SOCKET
    #else
        #defube PCAP_SOCKET int
    #endif
#endif

and use PCAP_SOCKET.

(backported from commit 93bac35)

Doing so can cause namespace collisions, as per, for example,
firnsy/barnyard2#245.

Instead, define PCAP_SOCKET, and use that.

On Windows, this shouldn't break any APIs, as any code using the two
active-mode APIs that return a socket handle would probably be assigning
their return values to a SOCKET, and as, on Windows, we're defining
PCAP_SOCKET as SOCKET, there would be no type clash.

On UN*Xes, this might break code that uses one of the two active-mode
APIs that return a socket handle if those programs were written to
assign the return values of those APIs to a SOCKET, as we're no longer
defining SOCKET.  However, as those APIs are only provided if libpcap is
built with remote capture support - which is not the default - and as
they're somewhat painful to use, there's probably little if any code
that needs to compile for UN*X and that uses them.  If there *is* any
such code, it could do

    #ifndef PCAP_SOCKET
        #ifdef _WIN32
            #define PCAP_SOCKET SOCKET
        #else
            #defube PCAP_SOCKET int
        #endif
    #endif

and use PCAP_SOCKET.

(backported from commit 93bac35)
@guyharris guyharris merged commit f1b5d70 into the-tcpdump-group:libpcap-1.10 Jan 26, 2024
19 checks passed
@guyharris guyharris deleted the backport-93bac35f01137cb83de165fb1b60da700cd0bac0 branch January 26, 2024 05:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

1 participant