devkitARM gcc 10 strncpy false positive warning
Posted: Thu Jun 25, 2020 10:53 pm
Hello, I just found out a weird warning in the linking step of a c++17 3ds homebrew, that I haven't been able to replicate except on every compilation of that specific (unreleased for now) source:
I have a mInfo struct with a few char array members, the first of size 8, followed by sizes 16, 128 (mShortDesc), and 256 (mLongDesc).
When strncpy-ing from a std::string created from the utf16 to utf8 conversion of a SMDH's short description to the 128-long array (using 128 as the limit size), it warns saying:
even though mInfo.mShortDesc is of size 128 (0x80).
And when doing the same for the SMDH's long description to the 256 long array (with 256 as the limit), it says:
even though mInfo.mLongDescis of size 256 (0x100).
This looks like a compiler bug to me, because it seems to (wrongly) use the size of the previous member in the warning, so I thought it should be reported here (or maybe to gcc, but I'll let you do that if needed).
Thank you for the incredible libraries and software, I hope this can be fixed, or if it's not a bug and instead user error, know how not to do it.
I have a mInfo struct with a few char array members, the first of size 8, followed by sizes 16, 128 (mShortDesc), and 256 (mLongDesc).
When strncpy-ing from a std::string created from the utf16 to utf8 conversion of a SMDH's short description to the 128-long array (using 128 as the limit size), it warns saying:
Code: Select all
warning: 'strncpy' writing 128 bytes into a region of size 16 overflows the destination [-Wstringop-overflow=]
425 | strncpy(mInfo.mShortDesc, desc.c_str(), 0x80);
And when doing the same for the SMDH's long description to the 256 long array (with 256 as the limit), it says:
Code: Select all
warning: 'strncpy' writing 256 bytes into a region of size 128 overflows the destination [-Wstringop-overflow=]
427 | strncpy(mInfo.mLongDesc, desc.c_str(), 0x100);
This looks like a compiler bug to me, because it seems to (wrongly) use the size of the previous member in the warning, so I thought it should be reported here (or maybe to gcc, but I'll let you do that if needed).
Thank you for the incredible libraries and software, I hope this can be fixed, or if it's not a bug and instead user error, know how not to do it.