[ET Trac] [Einstein Toolkit] #223: Make declaration of CCTK_ARGUMENTS safer
Einstein Toolkit
trac-noreply at einsteintoolkit.org
Wed Nov 9 17:46:00 CST 2011
#223: Make declaration of CCTK_ARGUMENTS safer
--------------------------+-------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: review
Priority: minor | Milestone:
Component: Cactus | Version:
Resolution: | Keywords:
--------------------------+-------------------------------------------------
Comment (by rhaas):
In C casting away const is a valid operation. Unless there is also a
restrict keyword present the compiler cannot assume that an object
'''pointed to''' by a const pointer cannot change anyway since C allows
aliasing, ie this is valid code that does no invoke undefined behaviour:
{{{
void mystrcpy(char *s, const char *t)
{
while(*t) *s++ = *t++;
}
int main(void)
{
char blah[] = "foo";
mystrcpy(blah, blah);
printf("%s\n", blah);
return 0;
}
}}}
Changing a const object directly is invalid though (compilers are free to
allow it though, it seems to be "should" behaviour at least in C89).
C++ might differ (I remember having had a hard time getting rid of a const
once but then I don't know much of the darker corners of C++). Even with a
restrict argument casting away const should be fine since the compiler can
trace data dependece between the two pointers (though I am not sure what
the standard says about creating a secondary pointer from a restricted
pointer).
Casting away const is not nice of course :-)
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/223#comment:5>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
More information about the Trac
mailing list