OTBR_REST=ON: compile error in hash table of status codes

[markus-becker-tridonic-com]

Describe the bug

When compiling ot-br-posix on an older OpenWrt toolchain and enabling -DOTBR_REST=ON I am getting the following compile error:

In file included from /usr/src/toolchain/staging_dir/toolchain-arm_cortex-a9_gcc-4.8-linaro_glibc-2.19_eabi/arm-openwrt-linux-gnueabi/include/c++/4.8.3/bits/hashtable.h:35:0,
                 from /usr/src/toolchain/staging_dir/toolchain-arm_cortex-a9_gcc-4.8-linaro_glibc-2.19_eabi/arm-openwrt-linux-gnueabi/include/c++/4.8.3/unordered_map:47,
                 from /usr/src/toolchain/feeds/otbr/src/rest/resource.hpp:37,
                 from /usr/src/toolchain/feeds/otbr/src/rest/connection.hpp:41,
                 from /usr/src/toolchain/feeds/otbr/src/rest/rest_web_server.hpp:37,
                 from /usr/src/toolchain/feeds/otbr/src/rest/rest_web_server.cpp:29:
/usr/src/toolchain/staging_dir/toolchain-arm_cortex-a9_gcc-4.8-linaro_glibc-2.19_eabi/arm-openwrt-linux-gnueabi/include/c++/4.8.3/bits/hashtable_policy.h: In instantiation of 'struct std::__detail::_Hash_code_base<otbr::rest::HttpStatusCode, std::pair<const otbr::rest::HttpStatusCode, std::basic_string<char> >, std::__detail::_Select1st, std::hash<otbr::rest::HttpStatusCode>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, true>':
/usr/src/toolchain/staging_dir/toolchain-arm_cortex-a9_gcc-4.8-linaro_glibc-2.19_eabi/arm-openwrt-linux-gnueabi/include/c++/4.8.3/bits/hashtable_policy.h:1402:10:   required from 'struct std::__detail::_Hashtable_base<otbr::rest::HttpStatusCode, std::pair<const otbr::rest::HttpStatusCode, std::basic_string<char> >, std::__detail::_Select1st, std::equal_to<otbr::rest::HttpStatusCode>, std::hash<otbr::rest::HttpStatusCode>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Hashtable_traits<true, false, true> >'
/usr/src/toolchain/staging_dir/toolchain-arm_cortex-a9_gcc-4.8-linaro_glibc-2.19_eabi/arm-openwrt-linux-gnueabi/include/c++/4.8.3/bits/hashtable.h:174:11:   required from 'class std::_Hashtable<otbr::rest::HttpStatusCode, std::pair<const otbr::rest::HttpStatusCode, std::basic_string<char> >, std::allocator<std::pair<const otbr::rest::HttpStatusCode, std::basic_string<char> > >, std::__detail::_Select1st, std::equal_to<otbr::rest::HttpStatusCode>, std::hash<otbr::rest::HttpStatusCode>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<true, false, true> >'
/usr/src/toolchain/staging_dir/toolchain-arm_cortex-a9_gcc-4.8-linaro_glibc-2.19_eabi/arm-openwrt-linux-gnueabi/include/c++/4.8.3/bits/unordered_map.h:100:18:   required from 'class std::unordered_map<otbr::rest::HttpStatusCode, std::basic_string<char> >'
/usr/src/toolchain/feeds/otbr/src/rest/resource.hpp:152:53:   required from here
/usr/src/toolchain/staging_dir/toolchain-arm_cortex-a9_gcc-4.8-linaro_glibc-2.19_eabi/arm-openwrt-linux-gnueabi/include/c++/4.8.3/bits/hashtable_policy.h:1070:12: error: invalid use of incomplete type 'struct std::hash<otbr::rest::HttpStatusCode>'
     struct _Hash_code_base<_Key, _Value, _ExtractKey, _H1, _H2,
            ^
compilation terminated due to -Wfatal-errors.

To Reproduce Information to reproduce the behavior, including:

1. Git commit id: 7a53c4c
2. IEEE 802.15.4 hardware platform: N/A
3. Build steps
4. Network topology: RCP

Expected behavior A clear and concise description of what you expected to happen.

Console/log output If applicable, add console/log output to help explain your problem.

Additional context Add any other context about the problem here.

[wgtdkp]

@tttttangTH Any ideas?

[jwhui]

This appears to be a gcc bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60970

I think the only fixes are:

1. Avoid use of std::hash.
2. Use a newer version of gcc.

[markus-becker-tridonic-com]

This appears to be a gcc bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60970

I think the only fixes are:

1. Avoid use of std::hash.
2. Use a newer version of gcc.

I was fearing 2, since this is a vendored-OpenWrt toolchain.
Possibly I could include the patch referenced in Bugzilla.

[tttttangTH]

This appears to be a gcc bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60970

I think the only fixes are:

1. Avoid use of std::hash.
2. Use a newer version of gcc.

@tttttangTH Any ideas?

Will fix it soon.

[tttttangTH]

This issue has been fixed in second PR #537 for OTBR-REST, my solution is to specialize std::hash for HttpStatusCode. I'm not sure whether it is a better practice compared to avoiding using std::hash. @wgtdkp

I will now create a PR to fix this.

[wgtdkp]

This issue has been fixed in second PR #537 for OTBR-REST, my solution is to specialize std::hash for HttpStatusCode. I'm not sure whether it is a better practice compared to avoiding using std::hash. @wgtdkp

I will now create a PR to fix this.

@tttttangTH What about we avoid using a hash map by a static function?

const char *GetHttpStatus(ResponseCode aCode)
{
    switch (aCode)
    {
    case ...:
    
    }
}

Since the number of the response codes is static, we don't really need a map.

[tttttangTH]

This issue has been fixed in second PR #537 for OTBR-REST, my solution is to specialize std::hash for HttpStatusCode. I'm not sure whether it is a better practice compared to avoiding using std::hash. @wgtdkp
I will now create a PR to fix this.

@tttttangTH What about we avoid using a hash map by a static function?

const char *GetHttpStatus(ResponseCode aCode)
{
    switch (aCode)
    {
    case ...:
    
    }
}

Since the number of the response codes is static, we don't really need a map.

Yes, if we need to define another hash function for this, it does bring more complexity compared to just use switch.

[markus-becker-tridonic-com]

Confirmed that it works. Thanks!