Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.61%. Comparing base (a599557) to head (24cbd00).
Report is 1 commits behind head on master.

@@           Coverage Diff           @@
##           master    #6659   +/-   ##
=======================================
  Coverage   98.61%   98.61%           
=======================================
  Files          79       79           
  Lines       14559    14559           
=======================================
  Hits        14358    14358           
  Misses        201      201           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Generated via commit 24cbd00

Download link for the artifact containing the test results: ↓ atime-results.zip

Counter-intuitively, a SEXP being const doesn't preclude modification of the underlying value. This is because SEXP is an alias for a pointer type: const SEXP * xd is equivalent to struct SEXPREC * const * xd, so while the pointer xd[i] is const, the contents, *(xd[i]), are not.

We're not allowed to *(xd[i]) because we're no longer told what struct SEXPREC is, but SET_TRUELENGTH getting a copy of a const SEXP pointer as the function argument and modifying the pointed-to buffer doesn't break any rules.

Thanks for the explanation (which I'm still processing)!

I had noticed that the compiler doesn't care if we used const SEXP *xd, however I decided to take the current approach based on the "spirit" of const, namely it's telling the reader (as well as the compiler) 'this is "read-only"' (even though in practice the actual thing that is read-only is somewhat complex).

IMO understanding why const is technically allowed here requires too much reasoning about internal/implementation details of SEXP, and I am not seeing much downside to using (SEXP *) instead of making xd const.

That's reasonable. Besides, the memory is writeable anyway, so the cast will not introduce undefined behaviour.

A better explanation may be that the garbage collector cares about the pointed-to object remaining at the same address but not about its contents changing (we can't guarantee the latter at the C level).