[ET Trac] #2641: ML_BSSN macro usage bypasses personalized read/write macros

[Samuel Cupp]

#2641: ML_BSSN macro usage bypasses personalized read/write macros

 Reporter: Samuel Cupp
   Status: new
Milestone: 
  Version: development version
     Type: bug
 Priority: trivial
Component: Kranc

The new macros are designed to only give access to the variables listed by read/write declarations, but ML\_BSSN bypasses this sanity check with its \*\_Body internal functions. As an example, in ML\_BSSN/src/ML\_BSSN\_ADMBaseInterior.cc is the scheduled function

```
extern "C" void ML_BSSN_ADMBaseInterior(CCTK_ARGUMENTS)
{
  #ifdef DECLARE_CCTK_ARGUMENTS_ML_BSSN_ADMBaseInterior
  DECLARE_CCTK_ARGUMENTS_CHECKED(ML_BSSN_ADMBaseInterior);
  #else
  DECLARE_CCTK_ARGUMENTS;
  #endif
  DECLARE_CCTK_PARAMETERS;
```

which then calls

```
static void ML_BSSN_ADMBaseInterior_Body(const cGH* restrict const cctkGH, const int dir, const int face, const CCTK_REAL normal[3], const CCTK_REAL tangentA[3], const CCTK_REAL tangentB[3], const int imin[3], const int imax[3], const int n_subblock_gfs, CCTK_REAL* restrict const subblock_gfs[])        
{
  DECLARE_CCTK_ARGUMENTS;
  DECLARE_CCTK_PARAMETERS;
```

The various \*\_Body should \(ideally\) either have their required variables passed explicitly or use the macro of the parent function. While the two macros don’t produce different numerical results, the personalized macros help validate the code’s behavior. It is admittedly a pretty low-priority task, but using the new macro is preferred when possible.

--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2641/ml_bssn-macro-usage-bypasses-personalized
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/trac/attachments/20220920/12f3095b/attachment.html