So with GCC 4.4 and glibc 2.10, C++ support went, once again, stricter. Now, leaving aside all my possible comments on a language for which there is still an absolute vacuum of actual implementations years after publishing, let just look at what the problem is this time around.
The main issue, in which glibc 2.10 is also related, is that the C-style string functions now return pointers with the same constant modifier as they are given; so if you look for a characters in a constant string, it’ll return a constant string pointer, and vice-versa if you give it a variable string, it’ll return you a variable string pointer (more here if you’re bored).
This means that the following code will build fine with either GCC 4.3 or glibc 2.10 but will fail when both of those (or more recent) versions are used:
#include <cstring>
int main() {
char *foo = strchr("ciao", 'a');
}
% g++-4.3.3 test-const.cc -o test-const
% g++-4.4.0 test-const.cc -o test-const
test-const.cc: In function ‘int main()':
test-const.cc:4: error: invalid conversion from ‘const char*' to ‘char*'
The error from the compiler is quite real: you’re mixing up different type of variables, although in this particular instance you’re not doing anything wrong with it, but for instance take the following code rather than the one shown earlier:
#include <cstring>
int main() {
char *foo = strchr("ciao", 'a');
*foo = 'e';
}
This code is trying to change something that it shouldn’t; in particular, given the pointer is now pointing inside a literal, which is then inside the .rodata section of the ELF and in a shared, non-writeable area of memory, when executed this will cause a segmentation fault (a crash, for those not used to this terminology). But it can get less obvious and more sneaky, since instead of a literal, you could have a parameter, declared constant.
Of course, whenever you have a variable or a parameter that is declared constant, but is not actually residing in read-only memory areas (like .rodata), you’re just a cast away from having it non-constant. But then you’d be seeing the cast, and that would be like a yellow light sign. On the other hand, with the old method of just having the function cast away the constant modifier, it was less obvious at first sight.
Okay so we know what the problem is, why the error was introduced, let’s go down to business with what the problem is. I have seen more than a few patches out there that, to make software build on GCC 4.4/glibc 2.10 simply cast away the constant modifier, C-style:
#include <cstring>
int main() {
char *foo = (char*)strchr("ciao", 'a');
}
This is wrong. You should not do that. Why? Because you’re hiding a problem; in more than half the cases, the solution is simply to change the declaration of the variable:
#include <cstring>
int main() {
const char *foo = strchr("ciao", 'a');
}
Of course, this does not cover all the cases; there are a few when the pointer is actually used to change memory areas. In those cases, since fixing the issue might be overkill, I’d highly suggest a different syntax:
#include <cstring>
int main() {
char *foo = const_cast(strchr("ciao", 'a'));
*foo = 'e';
}
This uses the explicit const_cast keyword from C++, and the very fact that it’s an eyesore in the code should be enough to scream “Workaround!”, which is what it is in truth.
So please, don’t just cast it away C-style, give it a bit more thoughts, please!
I’ve seen people deal with warnings by casting too when usually the declaration is what should change. I have a question though. What’s your suggestion when the declaration is from a header? Changing it there can be an API change.
Technically, yes you’d be changing API. On the other hand if the parameter is declared const but is then _changed_ then the API is false and broken in the first place, and keeping it as it is might be even worse.
Thanks for this post. It really helped me a lot to understand what’s going on with gcc-4.4 and glibc-2.10 :)Cheers
I think it is important to follow Bjarne’s advice in general:Never use c-casts in C++ at all. Always use the c++-casts, and it will be clearer of what you are trying to achieve, or – like you describe in this post – what you might fail to achieve.Nice to see some differences between versions, I’ve never really paid attention to changes like this in GCC (g++).
Nice post. I am guilty of C style casting away warnings in C++ code. Only recently have I really changed my ways and embraced C++ style casting.
“Now, leaving aside all my possible comments on a language for which there is still an absolute vacuum of actual implementations years after publishing,” — like, say, complete C99? =) <http: gcc.gnu.org=”” gcc-4.4=”” c99status.html=””>
http://bugs.gentoo.org/show_bug.cgi?id=271605, #6