Thank all for your quick reply. I am wrong to say Rmpi does not modify
CHARSXP at C level. In fact as Martin points out, the receive buff must be
modified. Last night I started the modification of c codes.
For send buffer (no modification), I used
//copy from R 2.6.0 (not in previous versions)
cha
Hao Yu,
I spot two types of problematic code. Certainly the memcpy in
conversions.c:54 and 56 will cause problems, but I'm not sure whether
those functions are actually used?
The second paradigm is, e.g., Rmpi.c:561
MPI_Recv(CHAR(STRING_ELT(sexp_data,i)),
slen,MPI_CHAR,source,ta
I'm not sure what your sticking point here is. If mpi does not modify
data in a (char *) pointer, then that really is a (const char *) pointer
and the headers are being unhelpful in not telling the compiler that
the data are constant.
If that is the case you need to use casts to (char *) and t
Hi. I am the maintainer of Rmpi package. Now I have a problem regarding
the change of CHAR () in R 2.6.0. According to R 2.6.0 NEWS:
***
CHAR() now returns (const char *) since CHARSXPs should no
longer be modified in place. This change allows compilers to
warn or error about i