R devel - Jul 2014 - arguments to .Call(), .External should be read-only?

hi.  if i'm reading correctly, "Writing R Extensions" appears to
be
inconsistent on the question of whether the arguments passed to a
routine called via .Call() or .External() should considered read-only.
section 5.2, "Interface functions .C and .Fortran", says
----
However, when character vectors are used other than in a read-only way,
the .Call interface is much to be preferred.
----

which sort of implies (if one reads optimistically) that using .Call()
(by extension, again optimistically, .External()) one could treat
*character* vectors (and, again, optimistically, numeric, etc., vectors)
in a non-read-only way.

on the other (pessimistic) hand, section 5.9, "Handling R objects in
C",
says
----
Neither .Call nor .External copy their arguments: you should treat
arguments you receive through these interfaces as read-only.
----

for an application, i'd like to consider these writable.  assuming
sufficient warnings in the documentation, etc., is that permissable?

cheers, Greg Minshall

On 08/07/2014 10:05 AM, Greg Minshall wrote:
> hi.  if i'm reading correctly, "Writing R Extensions" appears
to be
> inconsistent on the question of whether the arguments passed to a
> routine called via .Call() or .External() should considered read-only.
> section 5.2, "Interface functions .C and .Fortran", says
> ----
> However, when character vectors are used other than in a read-only way,
> the .Call interface is much to be preferred.
> ----
>
> which sort of implies (if one reads optimistically) that using .Call()
> (by extension, again optimistically, .External()) one could treat
> *character* vectors (and, again, optimistically, numeric, etc., vectors)
> in a non-read-only way.
>
> on the other (pessimistic) hand, section 5.9, "Handling R objects in
C",
> says
> ----
> Neither .Call nor .External copy their arguments: you should treat
> arguments you receive through these interfaces as read-only.
> ----
>
> for an application, i'd like to consider these writable.  assuming
> sufficient warnings in the documentation, etc., is that permissable?
R doesn't necessarily copy variables on assignment, so code like this:

x <- y <- rnorm(10)

will create *one* vector of length 10, with both x and y referring to 
it.  If your code modifies x the changes will show up in y as well.  
That's the reason for the warning.

See section 5.9.10 for how to handle this safely, but pay attention to 
the last sentence of that section:  any code you write which does this 
is likely to require changes as R's memory management evolves. In 
particular, all of that section is likely to be wrong next spring when R 
3.2.0 is released, as there are changes in the works to implement better 
reference counting.  See <http://developer.r-project.org/Refcnt.html> 
for a discussion.

Duncan Murdoch