[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
-----BEGIN PGP SIGNED MESSAGE-----
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHNgoJ9p/Jzwa2QP4RAkeQAJ0Y0sMwWmb0k0u+3YI2lPXwBklpFQCfbCbk
sY72JmcqQ78DQClVxIJKoKU=
=3ZzG
-----END PGP SIGNATURE-----
More information about the R-devel
mailing list