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

Fix compiler warnings #9411

Open
wants to merge 7 commits into
base: master
Choose a base branch
from
Open

Fix compiler warnings #9411

wants to merge 7 commits into from

Conversation

Al2Klimov
Copy link
Member

No description provided.

@Al2Klimov Al2Klimov self-assigned this Jun 22, 2022
@cla-bot cla-bot bot added the cla/signed label Jun 22, 2022
@Al2Klimov Al2Klimov changed the title Silence compiler warnings Fix compiler warnings Jun 23, 2022
@Al2Klimov Al2Klimov force-pushed the compiler-warnings branch 5 times, most recently from 83d5d60 to 0a416bd Compare June 30, 2022 16:53
@Al2Klimov
Copy link
Member Author

@julianbrost Would you prefer me finish this or have this merged "ASAP" not to have it laying around for too long?

@Al2Klimov Al2Klimov added this to the 2.14.0 milestone Jul 25, 2022
@Al2Klimov
Copy link
Member Author

Btw. any idea what's the matter with the unused OpenSSL functions?

@Al2Klimov
Copy link
Member Author

Al2Klimov commented Jul 25, 2022

TODO

  • Have a look at Windows

@julianbrost
Copy link
Contributor

@julianbrost Would you prefer me finish this or have this merged "ASAP" not to have it laying around for too long?

What are the thing you would or wouldn't do in each case?

But I'd rather keep this PR at a reviewable size rather than growing it to some monster nobody got time for to review.

Btw. any idea what's the matter with the unused OpenSSL functions?

Which ones do you mean?

@Al2Klimov
Copy link
Member Author

@julianbrost Would you prefer me finish this or have this merged "ASAP" not to have it laying around for too long?

What are the thing you would or wouldn't do in each case?

But I'd rather keep this PR at a reviewable size rather than growing it to some monster nobody got time for to review.

I'm done anyway with not Windows-specific stuff.

Btw. any idea what's the matter with the unused OpenSSL functions?

Which ones do you mean?

lib/base/tlsutility.cpp:33:13: warning: unused function 'OpenSSLLockingCallback' [-Wunused-function]
lib/base/tlsutility.cpp:41:22: warning: unused function 'OpenSSLIDCallback' [-Wunused-function]

@julianbrost
Copy link
Contributor

Btw. any idea what's the matter with the unused OpenSSL functions?

Which ones do you mean?

lib/base/tlsutility.cpp:33:13: warning: unused function 'OpenSSLLockingCallback' [-Wunused-function]
lib/base/tlsutility.cpp:41:22: warning: unused function 'OpenSSLIDCallback' [-Wunused-function]

They are used with some functions up-to-date OpenSSL versions no longer use. So figure out if it's still used in any OpenSSL version we have to support and if so, put it in #ifdef, otherwise remove it.

@Al2Klimov
Copy link
Member Author

Oh, that's the point! They are inside #ifdefs... but reported as unused?!

@julianbrost
Copy link
Contributor

They are inside #ifdef CRYPTO_LOCK, not some version check. So probably some "do it if that version of OpenSSL already supports it", now it's no longer used and some defines were left there so that they don't actively break code.

@Al2Klimov
Copy link
Member Author

To me they seem to be still used. (Just search for them via Ctrl+F in the same file.) And the usages are in identical ifdefs.

@julianbrost
Copy link
Contributor

Used with this macro that expands to nothing (i.e. no use of the function):

#  define CRYPTO_set_locking_callback(func)

Which is inside:

# if OPENSSL_API_COMPAT < 0x10100000L

So looks like that function was deprecated with 1.1.0, and I think CentOS 7 still uses an older version (:

@Al2Klimov
Copy link
Member Author

Cool. /s

@Al2Klimov Al2Klimov removed their assignment Jul 26, 2022
@Al2Klimov Al2Klimov marked this pull request as ready for review July 26, 2022 15:40
Copy link
Contributor

@julianbrost julianbrost left a comment

Choose a reason for hiding this comment

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

In general, if we take the effort to address compiler warnings, we should also do something to ensure that it stays this way, i.e. CI.

I see two options here:

  1. Add a GH Actions job that compiles with -Werror. But this has the risk that at some point a new type of warning is added, not immediately addressed and the check will just be ignored.
  2. I don't know if something like this already exists, but I'd be surprised if it doesn't: GH Actions allow to annotate the code in a PR, so it should be possible to annotate it with compiler warnings.

Can you please look if something like this exists and integrate it?

CMakeLists.txt Outdated
Comment on lines 175 to 176
add_definitions(-DBOOST_ALLOW_DEPRECATED_HEADERS)

Copy link
Contributor

Choose a reason for hiding this comment

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

What's the reason for this change? Basically that just silences a warning, why can't what the warning is actually about be addressed?

Copy link
Member Author

Choose a reason for hiding this comment

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

We have to support a wide range of Boost versions, with possibly different headers being available/deprecated or not. We already (have to) support [1.66, 1.79], 14 different versions. If we gonna support e.g. CentOS 7 till 2024, that will increase. I consider it more productive not to care about header deprecation.

Copy link
Contributor

Choose a reason for hiding this comment

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

The purpose of that warning should be a heads-up notice that if you address it, you won't be surprised by the next Boost version breaking something.

Now I haven't looked at this in detail (would actually addressing these warnings involve adding huge amounts of #ifdef?) and how Boost handles deprecation (do deprecated headers stay there basically forever?).

Copy link
Member Author

Choose a reason for hiding this comment

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

do deprecated headers stay there basically forever?

Unfortunately I forgot my crystal ball. So I opt for hoping for that, but changing this strategy on bad surprise.

Copy link
Member Author

Choose a reason for hiding this comment

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

I mean: just have a look at the add_definitions immediately nearby.

void Configuration::SetApiBindHost(const String& val, bool suppress_events, const Value& cookie)
void Configuration::SetApiBindHost(const String& val, bool, const Value&)
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not a fan of addressing unused parameters like this. The names also serve a bit of a descriptive purpose. Without them, you have to find the signature that's implemented here or the call site to figure out what these parameters actually are.

Thus, I'd prefer (void) suppress_events; in instances like this. For something like MessageOrigin messageOrigin I'm fine with removing the name.

Copy link
Member Author

Choose a reason for hiding this comment

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

For used params, sure. One has to know what's what. But for unused? Who cares what that random bool is if no one uses it? After all in the (rare) case of (rare) cases these two red/green arrows in CLion next to the funcdef are your friends. Btw. we already do it like this.

Comment on lines 43 to 44
typedef std::pair<Object *, int> kv_pair;
for (const kv_pair& kv : it->second) {
typedef std::pair<Object *const, int> kv_pair;
for (kv_pair& kv : it->second) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Just use auto and get rid of the typedef?

lib/base/scriptutils.cpp Outdated Show resolved Hide resolved
@Al2Klimov
Copy link
Member Author

Actually this PR has never been about compiler warnings cleanup by itself. I as a dev just don’t want to get spammed with them as that hides everything else. I consider the current amount of warnings just fine. Apropos! Do you remember my TODO list? Its only point is checkboxed because I actually took a look at Windows (compiler warnings). Not more and not less. I decided not to care (for now), primarily to get this done. So no reason to overengineer anything.

@Al2Klimov Al2Klimov added this to awaits concept review (i.e. TBD) in 42 quadrillions PRs Jan 31, 2023
@Al2Klimov
Copy link
Member Author

Or to say it with your wording:

But I'd rather keep this PR at a reviewable size rather than growing it to some monster nobody got time for to review.

@Al2Klimov
Copy link
Member Author

By the way. Depending on the bison/flex version one can get these warnings:

build/tools/mkclass/class_lexer.cc:2090:58: warning: unused parameter 'yyscanner' [-Wunused-parameter]
static void yy_fatal_error (yyconst char* msg , yyscan_t yyscanner)
                                                         ^
build/tools/mkclass/class_lexer.cc:2434:43: warning: unused parameter 'yyscanner' [-Wunused-parameter]
void *yyalloc (yy_size_t  size , yyscan_t yyscanner)
                                          ^
build/tools/mkclass/class_lexer.cc:2439:58: warning: unused parameter 'yyscanner' [-Wunused-parameter]
void *yyrealloc  (void * ptr, yy_size_t  size , yyscan_t yyscanner)
                                                         ^
build/tools/mkclass/class_lexer.cc:2451:36: warning: unused parameter 'yyscanner' [-Wunused-parameter]
void yyfree (void * ptr , yyscan_t yyscanner)

@yhabteab You as a Mac user can fix these easily:

  • brew install bison
  • brew install flex
  • cmake: add -DBISON_EXECUTABLE=/usr/local/Cellar/bison/3.8.2/bin/bison -DFLEX_EXECUTABLE=/usr/local/Cellar/flex/2.6.4_2/bin/flex

@Al2Klimov Al2Klimov force-pushed the compiler-warnings branch 2 times, most recently from 3cf4202 to f68520d Compare March 23, 2023 12:40
@Al2Klimov
Copy link
Member Author

Used with this macro that expands to nothing (i.e. no use of the function):

#  define CRYPTO_set_locking_callback(func)

Which is inside:

# if OPENSSL_API_COMPAT < 0x10100000L

So looks like that function was deprecated with 1.1.0, and I think CentOS 7 still uses an older version (:

Yes, 1.0.2k. Good to know. openssl/openssl#1260 (comment)

@Al2Klimov Al2Klimov self-assigned this Mar 24, 2023
@Al2Klimov Al2Klimov removed their assignment Mar 24, 2023
@Al2Klimov Al2Klimov force-pushed the compiler-warnings branch 2 times, most recently from a5adc0f to 3ecc62d Compare March 24, 2023 17:08
@Al2Klimov Al2Klimov removed the request for review from julianbrost March 24, 2023 17:21
@Al2Klimov Al2Klimov self-assigned this Mar 24, 2023
@Al2Klimov Al2Klimov force-pushed the compiler-warnings branch 2 times, most recently from 3e1988e to abfeba7 Compare March 31, 2023 10:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
42 quadrillions PRs
awaits concept review (i.e. TBD)
Development

Successfully merging this pull request may close these issues.

None yet

2 participants