Re: [Rd] CHAR () and Rmpi

From: Martin Morgan <mtmorgan_at_fhcrc.org>
Date: Sat, 29 Sep 2007 07:21:12 -0700

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

______________________________________________
R-devel_at_r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Received on Sat 29 Sep 2007 - 14:26:11 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Mon 01 Oct 2007 - 12:41:32 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.