[ET Trac] #177: EXC_BAD_ACCESS in CarpetIOASCII

[Roland Haas]

#177: EXC_BAD_ACCESS in CarpetIOASCII

 Reporter: Ian Hinder
   Status: closed
Milestone: 
  Version: 
     Type: bug
 Priority: minor
Component: Carpet

Comment (by Roland Haas):

My guess would be that this is related to git hash [eb2c2b94](https://bitbucket.org/eschnett/carpet/commits/eb2c2b94649ce3217bba14cd73212bdeb9ea375d) "CarpetIOASCII: adapt to gdata::copy\_from being static" of \[carpet\]\([https://bitbucket.org/eschnett/carpet](https://bitbucket.org/eschnett/carpet) and git hash [6537e215](https://bitbucket.org/eschnett/carpet/commits/6537e215dbebd17b72b57abf422ecf02ac7d81fe) "CarpetLib: make gdata transfer functions static functions" of [carpet](https://bitbucket.org/eschnett/carpet). Before those Carpet/CarpetLib would use a NULL pointer to call \(non-virtual\) member functions that it “knew” would not actually access member variables due to arguments in the call. This was never quite legal \(`this` must not be NULL and must always \(even in the constructor\) point to a valid region of memory\).   
Essentially the compiler is free to optimize things like:  

```c++
foo::bar(int a) {
  if(a)
    return 0;
  int b = this->c;
  return ;
}
```

to

```c++
foo::bar(int a) {
  int b = this->c;
  if(a)
    return 0;
  return ;
}
```

since the standard guarantees that `this` is valid.

--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/177/exc_bad_access-in-carpetioascii
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/trac/attachments/20230117/d4cf906f/attachment.html