[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