chore(libs): fix -Werror=unused-variable

[clan]

What type of PR is this?

/kind bug

Any specific area of the project related to this PR?

/area build

Does this PR require a change in the driver versions?

No

What this PR does / why we need it:

otherwise test will give wrong result if compiler has -Werror flags, complained with:

error: unused variable 'g_ppm_class' [-Werror=unused-variable]

Does this PR introduce a user-facing change?:

No

NONE

[poiana]

Welcome @clan! It looks like this is your first PR to falcosecurity/libs 🎉

[github-actions]

Perf diff from master - unit tests

     4.46%     -1.05%  [.] sinsp_thread_manager::get_thread_ref
     1.42%     -1.02%  [.] 0x00000000000e93c0
     2.02%     +0.95%  [.] scap_event_decode_params
     1.69%     -0.76%  [.] std::vector<sinsp_evt_param, std::allocator<sinsp_evt_param> >::emplace_back<sinsp_evt*, unsigned int&, char const*, unsigned long&>
     1.68%     +0.75%  [.] std::_Hashtable<long, std::pair<long const, std::shared_ptr<sinsp_threadinfo> >, std::allocator<std::pair<long const, std::shared_ptr<sinsp_threadinfo> > >, std::__detail::_Select1st, std::equal_to<long>, std::hash<long>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, false, true> >::_M_find_before_node
     1.28%     +0.65%  [.] std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char const*>
     4.45%     -0.59%  [.] sinsp_evt::load_params
     0.91%     -0.54%  [.] scap_next
     4.59%     +0.53%  [.] gzfile_read
     0.60%     +0.48%  [.] sinsp_threadinfo::~sinsp_threadinfo

Heap diff from master - unit tests

peak heap memory consumption: 0B
peak RSS (including heaptrack overhead): 0B
total memory leaked: 0B

Heap diff from master - scap file

peak heap memory consumption: 0B
peak RSS (including heaptrack overhead): 0B
total memory leaked: 0B

Benchmarks diff from master

Comparing gbench_data.json to /root/actions-runner/_work/libs/libs/build/gbench_data.json
Benchmark                                                         Time             CPU      Time Old      Time New       CPU Old       CPU New
----------------------------------------------------------------------------------------------------------------------------------------------
BM_sinsp_split_mean                                            -0.0147         -0.0147           149           147           149           147
BM_sinsp_split_median                                          -0.0099         -0.0099           149           148           149           148
BM_sinsp_split_stddev                                          +0.8504         +0.8476             1             1             1             1
BM_sinsp_split_cv                                              +0.8780         +0.8751             0             0             0             0
BM_sinsp_concatenate_paths_relative_path_mean                  -0.0807         -0.0807            46            42            46            42
BM_sinsp_concatenate_paths_relative_path_median                -0.0484         -0.0484            44            42            44            42
BM_sinsp_concatenate_paths_relative_path_stddev                -0.9294         -0.9294             2             0             2             0
BM_sinsp_concatenate_paths_relative_path_cv                    -0.9232         -0.9232             0             0             0             0
BM_sinsp_concatenate_paths_empty_path_mean                     +0.0155         +0.0156            17            17            17            17
BM_sinsp_concatenate_paths_empty_path_median                   +0.0089         +0.0089            17            17            17            17
BM_sinsp_concatenate_paths_empty_path_stddev                   +2.2205         +2.2193             0             0             0             0
BM_sinsp_concatenate_paths_empty_path_cv                       +2.1712         +2.1701             0             0             0             0
BM_sinsp_concatenate_paths_absolute_path_mean                  -0.1540         -0.1540            50            42            50            42
BM_sinsp_concatenate_paths_absolute_path_median                -0.1556         -0.1555            50            42            50            42
BM_sinsp_concatenate_paths_absolute_path_stddev                -0.2603         -0.2602             1             1             1             1
BM_sinsp_concatenate_paths_absolute_path_cv                    -0.1256         -0.1256             0             0             0             0
BM_sinsp_split_container_image_mean                            -0.0111         -0.0111           353           349           353           349
BM_sinsp_split_container_image_median                          -0.0095         -0.0095           353           349           353           349
BM_sinsp_split_container_image_stddev                          +0.1862         +0.1856             2             3             2             3
BM_sinsp_split_container_image_cv                              +0.1995         +0.1989             0             0             0             0

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 73.55%. Comparing base (16ac62f) to head (ac8a21a).
Report is 3 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2058   +/-   ##
=======================================
  Coverage   73.55%   73.55%           
=======================================
  Files         253      253           
  Lines       31863    31863           
  Branches     5639     5631    -8     
=======================================
  Hits        23437    23437           
- Misses       8410     8414    +4     
+ Partials       16       12    -4     

Flag	Coverage Δ
libsinsp	73.55% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[FedeDP]

Thanks for this fix! Please note that CI issues are not caused by your PR; they are caused by #2053 that (correctly) enabled BUILD_WARNINGS_AS_ERRORS in CI.

Also, i think your fix is valuable for next driver release!
/milestone 7.3.0+driver

[FedeDP]

Hi! Can you rebase on latest master to fix the CI? :) thank you!

[clan]

Hi! Can you rebase on latest master to fix the CI? :) thank you!

done.

[FedeDP]

/approve

[poiana]

LGTM label has been added.

Git tree hash: 62b078793a34abef59dd3f3ca613bdeae86fd6e6

[poiana]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: clan, FedeDP

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• driver/OWNERS [FedeDP]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[hhoffstaette]

Out of curiosity, why does the cast fix this problem? It's side-effect-free and the compiler could still be allowed to delete everything except the return value.
Edit: this is not just a common convention/compatibility feature but actually in the C standard. 🧐

[clan]

Out of curiosity, why does the cast fix this problem? It's side-effect-free and the compiler could still be allowed to delete everything except the return value. Edit: this is not just a common convention/compatibility feature but actually in the C standard. 🧐

I think it's harmless for the feature test code, which won't cause run-time problem. I'm not sure whether there are any side effect (performance, etc.), may be depend on optimization level? What's the difference when compare to compiler's attribute (___attribute((unused)))? Will do more research when have time (by compare the generated asm code).

[hhoffstaette]

I'm not sure whether there are any side effect (performance, etc.), may be depend on optimization level? What's the difference when compare to compiler's attribute (___attribute((unused)))?

I put it into CompilerExplorer here and as expected there is no difference between the cast and ((unused)). As soon as you enable -O the store is optimized away (also expected). I've used ((unused)) before; my question was purely whether the void cast is some kind of historic convention that all compilers implement to be compatible with each other, or whether this is specified somewhere. Turns out it is. :)