#1379: Rename autoconfigured CCTK_BUILTIN functions to __builtin --------------------------+------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: review Priority: major | Milestone: Component: Cactus | Version: development version Resolution: | Keywords: --------------------------+-------------------------------------------------
Comment (by hinder):
Erik and I just discussed this, but didn't come to a conclusion. {{{__builtin_expect}}} is a gcc extension which is supported by some other compilers. As such, it is probably safe in practice for us to do as Erik suggests, and define it if it doesn't exist. However, I think we would be technically breaching the standards by doing this, as we are not a compiler implementation, so should not be defining things with double- underscore prefixes (according to the ANSI C standard). Erik also points out that we breach the standards in many other ways as well. Apart from this specific case, I think we should decide on a policy for this sort of thing. I am leaning towards the opinion that Cactus should only define things in its own namespace, rather than providing features from some compilers on others that users might expect. This touches on features such as "inline", "restrict" and "M_PI"; all of these are things that Cactus tries to define according to common usage or another standard, when the currently-compiled standard doesn't provide them. Issues of compatibility and portability seem to be complicated enough without Cactus defining symbols like this. The logical conclusion of this would be that Cactus defines CCTK_EXPECT, CCTK_INLINE, CCTK_RESTRICT and CCTK_PI as part of the "Cactus platform", and we guarantee that this will work everywhere Cactus is supported. It is then clear to the reader of the code that they are using a feature provided on some level by Cactus, rather than something which looks like a compiler-specific feature but is actually provided by Cactus. The resulting code looks more ugly (in the case of inline, restrict and M_PI, though arguably not in the case of {{{__builtin_expect}}}, but we have to deal with CCTK_ARGUMENTS, CCTK_REAL etc anyway, and at least it is clear when Cactus is involved.
Since the ET currently doesn't build on Datura, Erik and I agreed that he would just use the CCTK_ prefix for now, and defer the decision on policy until more people have weighed in.