Dear Simon,
On Sat, 2012-05-26 at 14:00 -0400, Simon Urbanek wrote:
> > My suggestion is that in the next release, it ought to be the
> > standard, documented behavior, not just because it's historical, but
> > because it's more convenient and safer.
>
> That is bogus - .C is inherently unsafe wrt vector lengths so talking
> about safety here is IMHO nonsensical. Your "safety" relies on bombing
> the program -
IMHO, not all memory errors are created equal. From the safety
perspective, an error that immediately bombs the program is preferable
to one that corrupts the memory, producing subtle problems much later or
one that reads the wrong memory area and goes into an infinite loop or
allocates gigabytes of RAM, etc..
> that is arguably much less safe than using checks that Brian was
> talking about because they are recoverable.
While undoubtedly useful for debugging, I don't think they are
particularly recoverable in practice. At best, they tell you that some
memory before or after that allocated has been overwritten. They cannot
tell you how much memory or whether R is now in an inconsistent state
(which may occur if the write is off by more than 64 bytes, I believe),
and should be restarted immediately, only taking the time to save the
data and history --- which is what a caught segfault in R does anyway,
at least on UNIX-alikes.
Furthermore, the guard bytes only trigger after the C routine exits, so
the error is only caught some time after it occurs, which makes
debugging it more difficult. (In contrast, a debugger like GDB can tell
exactly which C statement caused a segmentation fault.)
The one advantage guard bytes might have over NULL (for a 0-length
vector) is that an error caught by a guard byte might allow the
developer to browse (via options(error=recover)) the R function that
made the .C() call, but even that relies on the bug not overwriting more
than a few bytes, and it cannot detect improper reads.
> You can argue either way, but there is no winner - the real answer is
> use .Call() instead.
It seems to me that the 0-length->NULL approach still dominates on the
matter of safety and debugging, with a possible exception in what I am
pretty sure is a relatively rare scenario when the developer has passed
a 0-length vector via .C() _and_ it was written to _and_ the developer
wants to browse (using error=recover()) the R code leading up to the
problematic .C() call, rather than browse (via GDB) the C code that
triggered the segfault. In that scenario, the developer can still easily
infer what argument was passed as an empty vector and via what .C()
call. (Standardizing on 0-length->NULL does not preclude putting guard
bytes on non-empty vectors, of course.)
> > From the point of view of programmer convenience, a having a 0-length
> > vector on the R side always map to a NULL pointer on the C side provides
> > a useful bit of information that the programmer can use, while a
> > non-NULL pointer to no data isn't useful, and the current R-devel
> > behavior requires the programmer to pass the information about whether
> > it's empty through an additional argument (of which there is an upper
> > limit). For example, if a procedure implemented in C takes optional
> > weights, passing a double(0) that was translated to NULL could be used
> > to signal that there are no weights.
>
> That would be just plain wrong use that certainly should not be
> encouraged - you *have* to pass the length along with any vectors
> passed to .C (that's why you should not be even thinking of using .C
> in the first place!) so it is much safer to check that the length you
> passed is 0 rather than relying on special-casing into NULL pointers.
Not necessarily. In the weighted data scenario, the length of the data
vector would, presumably, be passed in a different argument, and, if
weights exist, their length would equal to that. The NULL here could be
a binary signal not to use weights.
While I understand that .Call() interface has many advantages
over .C(), .C() remains a simple and convenient interface that doesn't
require the developer to learn too much about R's internals, and, either
way, as long as the .C() interface is not being deprecated, I think that
it ought to be made as safe and as useful as possible.
Best,
Pavel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
