You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Fix for buffer overflow in fp_traits.hpp on aarch64 / mingw #1348
We can handle this for sure. But we should discuss a few details in order to find the best way to handle this issue.
It looks like you are getting an error via -Werror regarding a suspected buffer overflow. Some similar warnings we encountered in the past have proven to be false negative, bogus warnings.
So we need to see if the warning can safely be disabled for this compiler and code sequence. if so, then we simply disable the warning within a PP-block in the header itself.
So just to be sure, without -Werror, is this just a warning?
Then we can look at the warning and try to determin if it is real/bogus.
Then potentially disable.
And yes, the hard-coded number 4 does look like it might simply be wrong for this architecture. We need to catch that if this is the case. Then that would be a real warning/error and not a bogus one.
And yes, the hard-coded number 4 does look like it might simply be wrong for this architecture. We need to catch that if this is the case. Then that would be a real warning/error and not a bogus one.
It's based on the assumption that the final #else is always a 128-bit long double, but this DR proves that not to be true, so maybe we should add a bit more error checking... I'll file a PR.
Activity
ckormanyos commentedon Jan 10, 2026
Hi @joostn, thanks for this good find.
We can handle this for sure. But we should discuss a few details in order to find the best way to handle this issue.
It looks like you are getting an error via
-Werrorregarding a suspected buffer overflow. Some similar warnings we encountered in the past have proven to be false negative, bogus warnings.So we need to see if the warning can safely be disabled for this compiler and code sequence. if so, then we simply disable the warning within a PP-block in the header itself.
So just to be sure, without
-Werror, is this just a warning?Then we can look at the warning and try to determin if it is real/bogus.
Then potentially disable.
ckormanyos commentedon Jan 10, 2026
And yes, the hard-coded number
4does look like it might simply be wrong for this architecture. We need to catch that if this is the case. Then that would be a real warning/error and not a bogus one.jzmaddock commentedon Jan 11, 2026
It's based on the assumption that the final #else is always a 128-bit long double, but this DR proves that not to be true, so maybe we should add a bit more error checking... I'll file a PR.
joostn commentedon Jan 11, 2026
I tested it for the 5 clang toolchains I have at hand:
I think it would be good to add static assertions to fp_traits.hpp, mismatches would be caught at compile time
Update fptraits.hpp for gcc/windows/aarch64.
ckormanyos commentedon Jan 24, 2026
I'd like to support embedded
arm-none-eabialso, even if this is not an OFFICIALLY supported compiler, it's nice to have in Math.ckormanyos commentedon Jan 24, 2026
See also #1352
NAThompson commentedon Sep 20, 2026
Resolved on develop