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

Jump to bottom

Undeclared identifier EOPNOTSUPP under win32 #183

Closed
nnposter opened this issue Jul 7, 2015 · 2 comments
Closed

Undeclared identifier EOPNOTSUPP under win32 #183

nnposter opened this issue Jul 7, 2015 · 2 comments
Labels
bug have code

Comments

@nnposter
Copy link

nnposter commented Jul 7, 2015

Compilation of r34854 with Visual Studio 2010 fails with

service_scan.cc(2559): error C2065: 'EOPNOTSUPP' : undeclared identifier

The root cause appears to be the absence of the corresponding definition in nbase/nbase_winunix.h. The following patch rectifies the issue:

--- a/nbase/nbase_winunix.h 2015-06-28 10:49:40.000000000 -0600
+++ b/nbase/nbase_winunix.h 2015-07-06 18:10:35.876970500 -0600
@@ -242,6 +242,8 @@
 #define ENOBUFS         WSAENOBUFS     /* No buffer space available */
 #undef EMSGSIZE
 #define EMSGSIZE        WSAEMSGSIZE    /* Message too long */
+#undef EOPNOTSUPP
+#define EOPNOTSUPP      WSAEOPNOTSUPP  /* Operation not supported */
 #undef  ENOMEM
 #define ENOMEM          WSAENOBUFS
 #undef  ENOTSOCK
@dmiller-nmap
Copy link

@nnposter We skipped over VS 2010 in our own builds, so we did not encounter this problem, but we ran into other problems on VS 2013. As a workaround, we added the _MSC_VER check in nbase_winunix.h which seems to be working well. Could you try changing the version there from "1800" (VS 2013) to "1600" (VS 2010) and see if it solves the problem? Otherwise, we'll apply your fix.

@nnposter
Copy link
Author

nnposter commented Jul 7, 2015

Sourcing errno.h (by changing the _MSC_VER condition) takes care of the missing EOPNOTSUPP but it exposes the class/struct bug that Gisle recently reported, which was until then latent. Applying his fix makes everything compile without errors.

It seems to me that perhaps both changes (the conditional and the custom definition) should be applied. Otherwise we would not be treating the error codes consistently, such as EOPNOTSUPP vs EMSGSIZE.

@gojimmypi gojimmypi mentioned this issue Feb 11, 2019
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug have code
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@nnposter @dmiller-nmap