[Rcpp-devel] assert() for Rcpp?

Tue Feb 24 18:00:22 CET 2015

On Tue, Feb 24, 2015 at 10:59 AM, Tim Keitt <tkeitt at utexas.edu> wrote:

>
>
> On Tue, Feb 24, 2015 at 9:45 AM, Miratrix, Luke <lmiratrix at fas.harvard.edu
> > wrote:
>
>>
>> As an inexperienced person myself, I was trying to wrap a C++ stand-alone
>> package so it could be called from R and was trying to preserve some of
>> the safety features and error-checking.  My understanding of asserts is
>> they are to catch disasters that indicate bugs in the code itself, and are
>> thus distinct from normal exceptions.  They therefore print out the failed
>> check and a line-number in the source file and bail.
>>
>> When using Rcpp, I came up against CRAN¹s admonition to not print to
>> stderr and so couldn¹t use assert() and stay ³legal.²  But I found this
>> out only after annoying people by not doing what I was supposed to do.
>> Given that, having assert() redefined so it is compliant with CRAN and
>> plays nice with R, but also maintains its behavior would be pretty cool, I
>> think.
>>
>> All this being said, Nathan Kurz¹s comments also seem good except I think
>> it is ³illegal² to print to STDERR directly before aborting, since it is
>> only aborting the C++ part, and not the entire R session.  Hence my hack
>> of printing to a string buffer and then handing it to the Rf_error call.
>> I don¹t know the guts of Rf_error, but I had assumed it would copy the
>> string to its own world before unwinding the stack.  If it doesn¹t then I
>> agree this is going to cause problems.  What is the correct way to pass a
>> message up, then?
>>
>
> If I recall, the other prohibition of CRAN is to never ever call abort (R
> owns the event loop) so assert-like behavior is not gonna fly.
>

Double negative, but you get the idea.

>
> THK
>
>
>>
>>
>> (Sorry for delay in posting this: the rcpp devel list does not get along
>> with my mail client.)
>>
>>
>>
>> Sincerely,
>>
>> Luke Miratrix
>> Assistant Professor of Statistics
>>
>>         Note: Due to my RSI (wrist trouble), e-mail often abrupt.
>>
>>
>> --
>>
>> Department of Statistics
>> Science Center
>>
>> Harvard University
>> 1 Oxford Street
>> Cambridge MA 02138-2901
>>
>>
>> lmiratrix at stat.harvard.edu
>> 510-735-7635
>>
>>
>>
>>
>>
>>
>> On 2/18/15, 3:25 PM, "Dale Smith" <DSmith at nexidia.com> wrote:
>>
>> >I haven't been very active lately with Rcpp, but I like Nathan's advice
>> >below. Don't redefine assert(), I think that's not friendly to
>> >inexperienced people and will just generate more questions.
>> >
>> >Dale Smith, Ph.D. | Data Scientist | nexidia | office: +1 404 495 7220
>> >ext 4008 | fax: +1 404 495 7221| nexidia.com
>> >
>> >-----Original Message-----
>> >From: rcpp-devel-bounces at lists.r-forge.r-project.org
>> >[mailto:rcpp-devel-bounces at lists.r-forge.r-project.org] On Behalf Of
>> >Nathan Kurz
>> >Sent: Wednesday, February 18, 2015 3:19 PM
>> >To: Miratrix, Luke
>> >Cc: rcpp-devel at lists.r-forge.r-project.org
>> >Subject: Re: [Rcpp-devel] assert() for Rcpp?
>> >
>> >On Tue, Feb 17, 2015 at 4:41 PM, Miratrix, Luke
>> ><lmiratrix at fas.harvard.edu> wrote:
>> >> The proposed code:
>> >>
>> >> #include <stdio.h>
>> >>
>> >> #ifdef NDEBUG
>> >> # define assert(EX)
>> >> #else
>> >> # define assert(EX) (void)((EX) || (__assert (#EX, __FILE__,
>> >> __LINE__),0)) #endif
>> >>
>> >> void __assert (const char *msg, const char *file, int line) {
>> >>     char buffer [100];
>> >>     snprintf( buffer, 100, "Assert Failure: %s at %s line #%d", msg,
>> >> file, line );
>> >>     ::Rf_error( buffer );
>> >> }
>> >
>> >Getting more people using assert-like macros seems like a great idea.
>> >Weighing in as a C programmer with limited knowledge of Rcpp, I'd
>> >suggest:
>> >
>> >1) Don't redefine assert() or __assert().  You'll confuse people and it
>> >will somehow manage to break things.  Instead, define your own macro with
>> >a different name, likely one in all caps that starts with "R_" or
>> "RCPP_".
>> >
>> >2) Only keep the name 'assert' in the macro if you are keeping the
>> >semantics of assert(), that is, it dies on failure if NDEBUG not defined.
>> > If it prints a warning and recovers, or defaults to off, use
>> >a different word.   I personally don't like the inverted NDEBUG
>> >approach, so would suggest a different semantics and different word.
>> >
>> >3) It's debatable if you want to allow it to be turned off or not.
>> >If it can be turned off, people will misuse it to guard against errors
>> >and be surprised when it doesn't.   I often use a noisy warning that
>> >only runs when DEBUG is positively defined (DEBUG_WARN_IF) and an abort
>> >that  cannot be turned off (ERROR_ABORT_IF).
>> >
>> >4) Don't try to snprintf() to a local buffer and then return.   I
>> >don't know C++ semantics for exceptions, but at least in C, combining
>> >local stack variables with stack unwinding is asking for trouble.  If you
>> >are aborting, print to STDERR directly.  If you are continuing, use a
>> >normal heap allocation.
>> >
>> >Nathan Kurz
>> >nate at verse.com
>> >_______________________________________________
>> >Rcpp-devel mailing list
>> >Rcpp-devel at lists.r-forge.r-project.org
>> >https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>>
>> _______________________________________________
>> Rcpp-devel mailing list
>> Rcpp-devel at lists.r-forge.r-project.org
>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>
>
>
>
> --
> http://www.keittlab.org/
>

-- 
http://www.keittlab.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20150224/462ce648/attachment-0001.html>