core: address error=array-bounds in gcc14

[yperbasis]

Address the following error when compling with gcc 14.2:

at /home/andrew/silkworm/silkworm/core/common/small_map.hpp:48:15,
    inlined from ‘static std::optional<silkworm::protocol::bor::Config> silkworm::protocol::bor::Config::from_json(const nlohmann::json_abi_v3_11_3::json&)’ at /home/andrew/silkworm/silkworm/core/protocol/bor/config.cpp:71:50:
/usr/include/c++/14/bits/stl_pair.h:607:48: error: array subscript [15, 576460752303423485] is outside array bounds of ‘const silkworm::SmallMap<long unsigned int, long unsigned int> [1]’ [-Werror=array-bounds=]
  607 |         second = std::forward<second_type>(__p.second);
      |                                            ~~~~^~~~~~
/home/andrew/silkworm/silkworm/core/protocol/bor/config.cpp: In static member function ‘static std::optional<silkworm::protocol::bor::Config> silkworm::protocol::bor::Config::from_json(const nlohmann::json_abi_v3_11_3::json&)’:
/home/andrew/silkworm/silkworm/core/protocol/bor/config.cpp:71:50: note: at offset [240, 9223372036854775760] into object ‘<anonymous>’ of size 136
   71 |     config.period = {period.begin(), period.end()};
      |                                                  ^

[chfast]

So you think this is a false positive warning?

[battlmonstr]

is this still needed given the if-check above?

[yperbasis]

is this still needed given the if-check above?

The error is still emitted unfortunately even with the check.

[battlmonstr]

could you clarify the error? how does a big number like "576460752303423485" or "9223372036854775760" end up there despite the check? who is passing that number? could it be that if is faulty due to some signed-unsigned UB?

[yperbasis]

I don't know where this number comes from (it's some internal details of the array-bounds check in gcc). The comparison is fine (both arguments are of type size_t).

[chfast]

This warning comes from optimized GCC builds. After some optimizations related to inlining and constant propagation compiler can convince itself that it knows the access index of an array and compare it with the array size.
Unfortunately, this analysis is known to have false-positives, see e.g.

• https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100038
• https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107699

If we want to be nice and you think it is worth the time I can reduce this example and report an issue. Or I can make a tutorial how to reduce failing compilations.

[yperbasis]

So you think this is a false positive warning?

Yes, I think so