[Rd] C/C++ 'assert' should not be used in R packages

Duncan Temple Lang duncan at wald.ucdavis.edu
Sat Nov 10 20:44:09 CET 2007

Hash: SHA1

Duncan Murdoch wrote:
> On 10/11/2007 1:00 PM, Duncan Temple Lang wrote:
> Duncan Murdoch wrote:
>>>> Prof Brian Ripley wrote:
>>>>> Please don't use 'assert' in R packages.  If called, this means that
>>>>> an error in your code aborts the whole R process, including your
>>>>> user's work. I see several R packages doing this, and one of them
>>>>> called 'assert' on me earlier in the week.
>>>> I partly disagree about this.  If assert() is triggered, it clearly
>>>> indicates a bug in the package.  If it just generated an R error,
>>>> most users would ignore it, and not report it to the package maintainer.
>>>> It may well be that when an assertion fails, none of the subsequent
>>>> calculations are reliable, in which case returning control to the
>>>> user could result in data corruption.  That's worse than losing a
>>>> session, because at least when you lose a session, you know it.
>>>> Could we write our own implementation of assert() that displays an R
>>>> error and unloads the package?  I think I could do something like
>>>> that in Windows by calling FreeLibrary to unload the DLL, but I'd
>>>> prefer a cross-platform solution.
> I am not sure why you think we need to discard the DLL.

I don't think this is worth spending much time on other than to
encourage you not to use FreeLibrary or its equivalents on
other systems and to use the R mechanisms.

However, just to clarify.

>> The package author has asserted that it is no longer safe to run.  

run _what_ ?  The R session? The computer? ....
 The object is important here.

assert() typically means that something unexpected in that routine
or in our case the sequence of calls from .C/.Call/...
So to assume that the session is no longer safe seems to be a large leap
from this particular invocation is unsafe to run to normal completion.
As with most things, it is a matter of scope and a simple mechanism
such as assert() leaves the intentions of the programmer unclear.

But of course it should not terminate the R session.  Nor should
R package developers link to libraries that make call the C routine
exit()  as this too will terminate the R session. One can use
techniques to mask such calls to exit() in some circumstances.

>> They
>> are shutting down R, and Brian finds that too extreme.

> What if we want to access variables and routines merely to find out
> the resulting state after the assert().
> And it is not clear whether you mean any "subsequent calculations"
> or any "subsequent calculations using code within this DLL"
> might be unreliable.
>> How could I know why a package author decided a shutdown is needed?  It
>> depends on the author.
> But regardless of that and the assumption that users will ignore this
> error, why would you want to call FreeLibrary? Since R has induced the
> DLL to be loaded either directly or indirectly, R holds a handle to the
> DLL. If you don't use R's cross-platform facilities for releasing the
> DLL (either at the R or C-level), you will corrupt the session,
> specifically in the list of assumed-live DLLs.
>> As I said, I'd prefer a cross-platform solution.
>> Duncan Murdoch
>  D.
>>>>> We provide 'error': please do use it to return control to the user
>>>>> when your code misbehaves.
>>>>> Similarly 'exit' and 'abort' should never be used in R packages.
>>>>> Sometimes it is not under your control: I sometimes see an rgl
>>>>> failure at
>>>>> R: indirect_vertex_array.c:659: emit_DrawArrays_old: Assertion
>>>>> `elements_per_request >= count' failed.
>>>>> that is coming from the Mesa GL libraries.
>>>> I'd say that's a bug, either in Mesa GL or in rgl.  If you can make
>>>> it reproducible, I'll try to track it down.
>>>> Duncan Murdoch
>>>> ______________________________________________
>>>> R-devel at r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the R-devel mailing list