search for: maybe_shar

> To allow for future changes in the way the need for duplication is > detected in R internal C code, package C code should avoid direct > use of NAMED,and SET_NAMED, or assumptions on the maximal value > of NAMED. Use the macros MAYBE_REFERENCED, MAYBE_SHARED, and > MARK_NOT_MUTABLE instead. These currently correspond to > > MAYBE_REFERENCED(x): NAMED(x) > 0 > MAYBE_SHARED(x): NAMED(x) > 1 > MARK_NOT_MUTABLE(x): SET_NAMED(c, NAMEDMAX) > > Best, > > luke Checking https://cran.r-project.org/doc/manuals/r-r...

Experimenting with altrep objects and v3 serialization, I discovered a possible bug. Calling DATAPTR on a compact_intseq object returns a pointer to the expanded integer sequence in memory. If you modify this data, the object values appear to be changed. However, if the compact_intseq object is then serialized (with version=3), only the original integer sequence info is written. For example,

...C++ standards (e.g., -std=gnu++11 for the C++11 compiler). Previously this was not done in a few cases where the default standard passed the tests made (e.g. clang 6.0.0 for C++11). C-LEVEL FACILITIES: * 'Writing R Extensions' documents macros MAYBE_REFERENCED, MAYBE_SHARED and MARK_NOT_MUTABLE that should be used by package C code instead NAMED or SET_NAMED. * The object header layout has been changed to support merging the ALTREP branch. This requires re-installing packages that use compiled code. * 'Writing R Extensions' now do...

...C++ standards (e.g., -std=gnu++11 for the C++11 compiler). Previously this was not done in a few cases where the default standard passed the tests made (e.g. clang 6.0.0 for C++11). C-LEVEL FACILITIES: * 'Writing R Extensions' documents macros MAYBE_REFERENCED, MAYBE_SHARED and MARK_NOT_MUTABLE that should be used by package C code instead NAMED or SET_NAMED. * The object header layout has been changed to support merging the ALTREP branch. This requires re-installing packages that use compiled code. * 'Writing R Extensions' now do...