Recently I was involved in testing of the API, which was working since years already, but required some refactoring for future use-cases. The API is used in the automotive ECU, powered by ARM processors. Nothing really special or difficult, but…<\/p>\n\n\n\n
The API was using a data and its SHA-256 digest, both represented by As the API was surely working, my suspicions turned towards the test code. But after checking it dozen of times, I couldn’t find anything wrong. Suddenly I realized, that test code is compiled and executed in development enviromnent under x86, while the API is used in armv8 target. The So what really happened? When comparing the How to fix the code and make it working, independent of the processor architecture? Seems that using a simple predicate solves the issue and quarantees that compared values have correct types:<\/p>\n\n\n As a conclusion<\/strong>: beware of signed and unsigned value comparison, have in mind potential overflows and care about code portability.<\/p>\n\n\n\n <\/p>\n","protected":false},"excerpt":{"rendered":" Recently I was involved in testing of the API, which was working since years already, but required some refactoring for future use-cases. The API is used in the automotive ECU, powered by ARM processors. Nothing really special or difficult, but… The API was using a data and its SHA-256 digest, both represented by std::string. Such […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"zakra_sidebar_layout":"customizer","zakra_remove_content_margin":false,"zakra_sidebar":"customizer","zakra_transparent_header":"customizer","zakra_logo":0,"zakra_main_header_style":"default","zakra_menu_item_color":"","zakra_menu_item_hover_color":"","zakra_menu_item_active_color":"","zakra_menu_active_style":"","zakra_page_header":true,"_eb_attr":"","om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[17,16],"tags":[22,8,7],"class_list":["post-800","post","type-post","status-publish","format-standard","hentry","category-c","category-development","tag-c-2","tag-development","tag-software"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/codevision.net.pl\/index.php\/wp-json\/wp\/v2\/posts\/800","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/codevision.net.pl\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/codevision.net.pl\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/codevision.net.pl\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/codevision.net.pl\/index.php\/wp-json\/wp\/v2\/comments?post=800"}],"version-history":[{"count":12,"href":"https:\/\/codevision.net.pl\/index.php\/wp-json\/wp\/v2\/posts\/800\/revisions"}],"predecessor-version":[{"id":835,"href":"https:\/\/codevision.net.pl\/index.php\/wp-json\/wp\/v2\/posts\/800\/revisions\/835"}],"wp:attachment":[{"href":"https:\/\/codevision.net.pl\/index.php\/wp-json\/wp\/v2\/media?parent=800"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/codevision.net.pl\/index.php\/wp-json\/wp\/v2\/categories?post=800"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/codevision.net.pl\/index.php\/wp-json\/wp\/v2\/tags?post=800"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}std::string<\/code>. Such an input was then validated internally by calculating the SHA-256 of data and comparing both hashes. Calculated hash was represented by std::vector<uint8_t><\/code>. Surprisingly, produced test cases were failing, even if the content was exactly the same!<\/p>\n\n\n\nstd::string user_input = "\\x9f\\x68\\x12\\x0a";\nstd::vector<uint8_t> calculated_input {0x9f, 0x68, 0x12, 0x0a};\n\nassert(user_input.size() == calculated_input.size());\nassert(std::equal(std::begin(user_input), std::end(user_input), std::begin(calculated_input)));\n<\/pre><\/div>\n\n\nstd::string<\/code> is storing and manipulating the sequence of character-like objects defined by character traits. Whether the underlying char<\/code> (or its variant) type is signed or unsigned, depends on the platform and compiler. In most x86 GNU\/Linux and Microsoft systems the char<\/code> type is signed. For ARM of PowerPC in turn, it is rather unsigned. The trace was confirmed, after running the test cases in the target.<\/p>\n\n\n\nstd::string<\/code> with std::vector<uint8_t><\/code> content there is a comparison of (signed) char<\/code> with uint8_t<\/code> value. In such case the compiler converts signed value to unsigned and performs the comparison of unsigned values. If any value of individual character in std::string<\/code> exceeds the range of signed char<\/code> (here: 127 = 0x7F), then it is treated as negative value (overflow). During the comparison with uint8_t<\/code> value it is casted to some huge unsigned number. In effect the std::equal<\/code> fails with comparison.<\/p>\n\n\n\nsigned char x = 127;\nstd::cout << "x = " << (int)x << std::endl; \/\/ x = 127\nsigned char y = 128;\nstd::cout << "y = " << (int)y << std::endl; \/\/ y = -128\nunsigned int z = y;\nstd::cout << "z = " << (unsigned int)z << std::endl; \/\/ z = 4294967168\n<\/pre><\/div>\n\n\n
\nassert(std::equal(std::begin(user_input), std::end(user_input), std::begin(calculated_input), [](uint8_t lhs, uint8_t rhs) { return lhs == rhs; }));\n<\/pre><\/div>\n\n\n