A value of type "const char [33]" cannot be used to initialize an entity of type "const unsigned char [32]" (C string ends \0 symbol)
BUG: array bounds overflow #227
pull fsb4000 wants to merge 1 commits into bitcoin-core:master from fsb4000:patch-1 changing 1 files +1 −1-
fsb4000 commented at 6:13 AM on March 8, 2015: none
-
BUG: array bounds overflow 4ff5e71e42
-
gmaxwell commented at 8:54 AM on March 8, 2015: contributor
This is valid C.
"(3.5.7) ... An array of character type may be initialized by a character string literal, optionally enclosed in braces. Successive characters of the character string literal (including the terminating null character if there is room or if the array is of unknown size) initialize the members of the array."
If you want to change it (e.g. to use this code in C++ where the behavior is different) the correct change would be to change the array length. I believe the value you've changed that to is not an element of the group. ( I actually thought one of my code reformatting diffs did that, but perhaps the commit got lost)
-
fsb4000 commented at 9:11 AM on March 8, 2015: none
https://msdn.microsoft.com/en-us/library/5awwxh25.aspx
Although it is possible not a bug in gcc. I do not know... -
gmaxwell commented at 9:13 AM on March 8, 2015: contributor
Your software is incorrect. I took the time to quote the actual text of the standard on that point...
It's not a question of GCC vs something else (though, indeed, GCC correctly does not produce any warning there unless you attempt to compile the code as C++), this is the actual definition of the C language. It may be that your software is running in a C++ mode, but libsecp256k1 is C not C++. Though no harm in making the software also compatible with C++, that can be done without changing the behavior at all. I went and dug up the prior change that hit this, you can see it in PR #228.
-
fsb4000 commented at 9:27 AM on March 8, 2015: none
Ok. Thank you.
- fsb4000 closed this on Mar 8, 2015
