Re: [Rd] Interrupting C++ code execution
Peter, On 25/04/11 10:22, schattenpfla...@arcor.de wrote: 1. Calling R_CheckUserInterrupt() interrupts immediately, so I have no possibility to exit my code gracefully. In particular, I suppose that objects created on the heap (e.g., STL containers) are not destructed properly. Sorry not to have seen this thread sooner. You may like to give CXXR a try (http://www.cs.kent.ac.uk/projects/cxxr/). In CXXR the R interpreter is written in C++, and a user interrupt is handled by throwing a C++ exception, so the stack is unwound in an orderly fashion, destructors are invoked, etc. However, it's fair to say that in using CXXR with a multi-threaded program you'll be on the bleeding edge... Andrew __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Memory allocation in C/C++ vs R?
Dominick, On 30/04/10 18:40, Dominick Samperi wrote: > Just to be sure that I understand, are you suggesting that the R-safe way to > do > things is to not use STL, and to not use C++ memory management and > exception handling? How can you leave a function in an irregular way without > triggering a seg fault or something like that, in which case there is no > chance > for recovery anyway? If you had time to try out your work with CXXR, I would be very interested to hear your experiences. Picking up on some of the points already raised in this thread: 1. CXXR's main program is written in C++, so it should deal with C++ initialisation and teardown correctly. (However, it has been so far tested only with gcc and the Intel C++ compiler, so there are doubtless plenty of submerged rocks still to discover.) 2. Within CXXR, all indirect flows of control are handled using C++ exceptions, and it is certainly the intention that user-supplied code should also be free to use C++ exceptions (subject to the caution that is always necessary in using C++ exceptions). 3. As regards memory allocation, in addition to the mechanisms available in standard R, you can of course use standard C++ 'new' and 'delete'. Also, objects of any C++ class that inherits directly or indirectly from CXXR::GCNode will be looked after by CXXR's own internal garbage collection. 4. Regarding protection from garbage collection, the mechanisms of standard R are available. But for C++ code, the preferred approach is to use the CXXR::GCRoot and CXXR::GCStackRoot smart pointers. Basically an object of one of these types behaves like a plain T* pointer (where T inherits from CXXR::GCNode), but whatever it points to is protected from garbage collection - for as long as the pointer exists and points to that object. Let me know (offline from this list) if I can be of any help. Andrew Runnalls __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] do_gsub (PR#10540)
Hin-Tak,
Apologies for the delay in responding.
On 2008/01/11 Hin-Tak Leung wrote:
> I believe STRING_ELT() works even when pat is R_NilValue, so
> the first line "does the right thing" even if the first element does not
> exist. I think this is intentional and not a bug.
>
> Other more knowledgeable people please correct me if I am wrong.
>
> [EMAIL PROTECTED] wrote:
>> In character.c within R 2.6.1, the function do_gsub contains the following
>> code:
>>
>> 1199if (STRING_ELT(pat, 0) == NA_STRING) {
>> 1200PROTECT(ans = allocVector(STRSXP, n));
>> 1201for(i = 0; i < n; i++) SET_STRING_ELT(ans, i, NA_STRING);
>> 1202UNPROTECT(1);
>> 1203return ans;
>> 1204}
>> 1205
>> 1206if (length(pat) < 1 || length(rep) < 1) error(R_MSG_IA);
>>
>> Line 1206 checks that pat contains at least one element. However,
>> line 1199 has already attempted to access the first element. The check
>> should surely come first.
Generally speaking, in the interests of software reliability and
maintainability, it is a good idea for part of a program to 'do the
right thing' itself - in the present case, to check that an array is
non-empty before assuming that it is - rather than relying on what is in
fact rather unusual behaviour of another part of the program. The case
I am concerned about is not in fact where 'pat' is R_NilValue, but when
it is a vector of length zero. When asked to create such a vector,
memory.c will in fact allocate some element space in the vector, which
is why the above problem doesn't manifest itself as a crash (in the
no-segfault.R test, for example, which explores this case); however, it
seems unwise to rely on this. And what would happen if that
(redundantly) allocated space just happened already to contain NA_STRING?
Best regards,
Andrew
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] strsignif.c, util.c (PR#10635)
Prof Brian Ripley wrote: > On Fri, 25 Jan 2008, [EMAIL PROTECTED] wrote: > >> In R 2.6.1, a couple of places (discovered using valgrind) where the >> requested size of string buffers fails to account correctly for the >> trailing null byte: >> >> 1. In src/appl/strsignif.c, 'f0' and 'form' at l. 108-9 each need at >> least 1 extra byte. >> >> 2. In src/main/util.c, 'out' at l. 1081 needs at least one extra byte. >> >> (Remember that the return value of strlen does not include the null >> byte.) > > But it is subtler than that. R_alloc contains the statement > > s = allocVector(RAWSXP, size + 1); > > and so does over-allocate by at least one (there is a rounding up to a > multiple of 8). This is a historical anomaly (it used to allocate a > CHARSXP that allowed for the null byte), but one which trying to > eliminate caused too many crashes in package code. > > I'd like to see the empirical evidence you have, as I have been unable > to trigger an overrun here. I should perhaps have explained that I discovered these faults working on a modified code base, in which in particular the valgrind instrumentation will pick up an overrun of even a single byte over the requested block size. I have no reason to suppose that the faults will lead to a failure of R as currently engineered; indeed for the reasons you cite I guess they won't. However, buffer overruns - when they do manifest themselves - can give rise to such baffling and hard-to-reproduce failures that they are like submerged rocks: well worth marking on the chart even if they're not close to current shipping lanes. Andrew Runnalls -- Dr Andrew Runnalls, Computing Laboratory, University of Kent, CANTERBURY CT2 7NF, UK Tel: (0)1227 823821 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] CXXR: Refactoring the R interpreter into C++
For a while now I have been working on a modified, but so far as possible fully functional, version of R in which the interpreter is progressively refactored (reengineered) from C to C++. The work is still at an early stage, but I think that sufficient progress has now been made for it to be of interest to some readers of this list. Further information is at http://www.cs.kent.ac.uk/projects/cxxr Andrew Runnalls -- Dr Andrew Runnalls, Computing Laboratory, University of Kent, CANTERBURY CT2 7NF, UK Tel: (0)1227 823821 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
