In C++ I have a function that only requires read-only access to an array but is mistakenly declared as receiving a non-const pointer:
size_t countZeroes( int* array, size_t count )
{
size_t result = 0;
for( size_t i = 0; i < count; i++ ) {
if( array[i] == 0 ) {
++result;
}
}
return result;
}
and I need to call it for a const array:
static const int Array[] = { 10, 20, 0, 2};
countZeroes( const_cast<int*>( Array ), sizeof( Array ) / sizeof( Array[0] ) );
will this be undefined behaviour? If so - when will the program run into UB - when doing the const_cast and calling the functon or when accessing the array?
Yes, it is allowed (if dangerous!). It's the actual write to a
const
object that incurs undefined behaviour, not the cast itself (7.1.5.1/4 [dcl.type.cv]).As the standard notes in 5.2.11/7 [expr.const.cast], depending on the type of the object an attempt to write through a pointer that is the result of casting away
const
may produce undefined behaviour.Using
const_cast
on an object which is initially defined asconst
is UB, therefore the undefined behaviour comes about immediately at the point you callconst_cast
.Yes, you can do that. No, it is not undefined behavior as long as the function truely does not try to write to the array.
Since your code does not modify the array, and you told the compiler you know what you are doing by using the
const_cast
, you will actually be OK. However, I believe you are technically invoking undefined behaviour. Best to get the function declaration fixed, or write, declare and use the const-safe version of it.The problem of
const_cast
is always the same -- it allows you to "break the rules", just like casting to and fromvoid*
-- sure you can do that, but the question is why should you?In this case it's of course ok, but you should ask yourself why didn't you declare
size_t countZeroes( const int* array, size_t count )
in the first place?And as a general rule about
const_cast
: