From mtmorgan at fhcrc.org  Sat Sep 29 16:21:12 2007
From: mtmorgan at fhcrc.org (Martin Morgan)
Date: Sat, 29 Sep 2007 07:21:12 -0700
Subject: [Rd] CHAR () and Rmpi
In-Reply-To: <Pine.LNX.4.64.0709290655440.19554@gannet.stats.ox.ac.uk> (Brian
	Ripley's message of "Sat, 29 Sep 2007 07:12:49 +0100 (BST)")
References: <65368.65.95.138.11.1191005668.squirrel@www.stats.uwo.ca>
	<Pine.LNX.4.64.0709290655440.19554@gannet.stats.ox.ac.uk>
Message-ID: <6phtzpdv9gn.fsf@gopher4.fhcrc.org>

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,tag, comm[commn],&status[statusn]);

where the first argument to MPI_Recv is a buffer that MPI_Recv will
fill. sexp_data is a user-supplied character vector. A not-clever
solution creates a temporary buffer via R_alloc (for garbage-collected
memory) or R_Calloc (for user-managed memory, probably appropriate in
a loop where you'd like to reuse the buffer), passes the buffer to
MPI_Recv, and then SET_STRING_ELT with the now filled temporary buffer
converted to a CHARSXP with mkChar. I think this is backward
compatible. The user-supplied character vector has gone to waste, used
only to pass in the length of the expected string. mkChar will copy
the temporary buffer (unless an identical CHARSXP already exists), so
that there are potentially three memory allocations per string!  I
suspect most users rely on higher-level access (mpi.par*Apply,
mpi.*.Robj, etc) where this inefficiency is not important or can be
addressed without modifying the public interface.

Martin

Prof Brian Ripley <ripley at stats.ox.ac.uk> writes:

> 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 the following 
> private define may be useful to you:
>
> #define CHAR_RW(x) ((char *) CHAR(x))
>
>
> However, you ask
>
>> Is there an easy way to get a char pointer to STRING_ELT((sexp_rdata),0) 
>> and is also backward compatible to old R versions.
>
> and the answer is that there is no such way, since (const char *) and 
> (char *) are not the same thing and any package that wants to alter the 
> contents of a string element needs to create a new CHARSXP to be that 
> element.
>
>
> BTW, you still have not changed Rmpi to remove the configure problems on 
> 64-bit systems (including assuming libs are in /usr/lib not /usr/lib64) I 
> pointed out a long time ago.
>
>
> On Fri, 28 Sep 2007, Hao Yu wrote:
>
>> 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 improper modification.  Thanks to Herve
>>        Pages for the suggestion.
>> *******
>> Unfortunately this causes Rmpi to fail since MPI requires char pointers
>> rather than const char pointers. Normally I use
>>    CHAR(STRING_ELT((sexp_rdata),0))
>> to get the pointer to MPI where a R character vector (C sense) is stored.
>> Because of the change, all character messengers fail. Is there an easy way
>> to get a char pointer to STRING_ELT((sexp_rdata),0) and is also backward
>> compatible to old R versions. BTW Rmpi does not do any modification of
>> characters at C level.
>>
>> Thanks
>> Hao Yu
>>
>>
>
> -- 
> Brian D. Ripley,                  ripley at stats.ox.ac.uk
> Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
> University of Oxford,             Tel:  +44 1865 272861 (self)
> 1 South Parks Road,                     +44 1865 272866 (PA)
> Oxford OX1 3TG, UK                Fax:  +44 1865 272595
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Martin Morgan
Bioconductor / Computational Biology
http://bioconductor.org



[Rd] CHAR () and Rmpi
Martin Morgan