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

lib: fix warnings about undefined macros #1362

Closed
wants to merge 1 commit into from

Conversation

MarcelRaad
Copy link
Member

@MarcelRaad MarcelRaad commented Mar 27, 2017

At least under Windows, there is no SIZEOF_LONG, so it evaluates to 0 even
though sizeof(int) == sizeof(long). This should probably have been
CURL_SIZEOF_LONG, but the type of timeout_ms changed from long to time_t
anyway.
Also defaulted USE_NTLM2SESSION to 0 if it's not defined so that MSVC warning
C4668 about implicitly replacing undefined macros with '0' can now be enabled.

@mention-bot
Copy link

@MarcelRaad, thanks for your PR! By analyzing the history of the files in this pull request, we identified @bagder, @yangtse and @captain-caveman2k to be potential reviewers.

@jay
Copy link
Member

jay commented Mar 28, 2017

I think we should require for all build systems either CURL_SIZEOF_LONG or SIZEOF_LONG and whichever one is required outlaw the other. Same for TIME_T.

@MarcelRaad
Copy link
Member Author

Yes, I've verified that SIZEOF_SIZE_T is defined in all config headers and SIZEOF_LONG isn't used anywhere else (but is defined in config-vxworks.h and curl_config.h). So it looks like CURL_SIZEOF_LONG would win over SIZEOF_LONG at this time.

But I find it a bit strange that CURL_SIZEOF_LONG is the only SIZEOF constant for a built-in type that has a CURL_ prefix and is defined in curlbuild.h. It was added there in feb03e4 and SIZEOF_LONG removed from config-symbian.h and config-tpf.h. 14240e9 initially moved only the curl-specific constants to curlbuild.h.

@bagder
Copy link
Member

bagder commented Mar 28, 2017

Symbols defined in our public header files must be "curl" prefixed, so if it is to be there it must be CURL_SIZEOF_LONG. But then I can't see any strong reason why it needs to be public in the first place...

@@ -53,6 +53,10 @@
#define USE_NTLM2SESSION 1
#endif

#if !defined(USE_NTLM2SESSION)
#define USE_NTLM2SESSION 0
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So what's the exact warning this fixes? I only see a !defined(USE_NTLM2SESSION) use of this and that looks perfectly fine to me?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Depending on how libcurl is built with ntlm USE_NTLM2SESSION is defined 0 or 1 or undefined. In ntlm code I notice there is a lot of #if FOO instead of #if defined(FOO). For example there is this twice:
#if USE_NTRESPONSES && USE_NTLM2SESSION
He has a compiler switch that catches when FOO macro is evaluated to 0 due to undefined FOO

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer that we rather make sure to depend on features with #ifdef so that we #undef features we don't have and we #define those we have. I think that's the pattern used more widely already. Defining to zero when we don't have it is an anomaly.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, exactly. All the macros defined in curl_ntlm_core.h and used in curl_ntlm_core.c and vauth/ntlm.c are checked with #if instead of #ifdef:
USE_NTLM_V2
USE_NTRESPONSES
USE_NTLM2SESSION
Seems like this is for historical reasons, they were always defined to 1 when introduced in 2006.

I'll glady change this in a separate pull request and remove the curl_ntlm_core.h changes from this one.

@@ -164,7 +164,7 @@ int Curl_socket_check(curl_socket_t readfd0, /* two sockets to read from */
int r;
int ret;

#if SIZEOF_LONG != SIZEOF_INT
#if SIZEOF_TIME_T != SIZEOF_INT
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, what a bug!

MarcelRaad added a commit to MarcelRaad/curl that referenced this pull request Mar 29, 2017
Feature defines are normally checked with #ifdef instead of #if in the rest of
the codebase. Additionally, some compilers warn when a macro is implicitly
evaluated to 0 because it is not defined, which was the case here.

Ref: curl#1362 (comment)
MarcelRaad added a commit to MarcelRaad/curl that referenced this pull request Mar 29, 2017
Feature defines are normally checked with #ifdef instead of #if in the rest of
the codebase. Additionally, some compilers warn when a macro is implicitly
evaluated to 0 because it is not defined, which was the case here.

Ref: curl#1362 (comment)
Closes curl#1367
@MarcelRaad MarcelRaad force-pushed the fix_undefined_macros branch from 9ed689f to 0c460a4 Compare March 29, 2017 18:29
At least under Windows, there is no SIZEOF_LONG, so it evaluates to 0 even
though sizeof(int) == sizeof(long). This should probably have been
CURL_SIZEOF_LONG, but the type of timeout_ms changed from long to time_t
anyway.
This triggered MSVC warning C4668 about implicitly replacing undefined
macros with '0'.

Closes curl#1362
@MarcelRaad MarcelRaad force-pushed the fix_undefined_macros branch from 0c460a4 to 1ff689a Compare March 29, 2017 18:31
@MarcelRaad
Copy link
Member Author

Updated and rebased after merging #1367 . Now only the change from SIZEOF_LONG to SIZEOF_TIME_T remains.

Copy link
Member

@bagder bagder left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch btw!

@MarcelRaad MarcelRaad deleted the fix_undefined_macros branch April 2, 2017 11:21
@lock lock bot locked as resolved and limited conversation to collaborators May 23, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants