[R] C API - no NULL pointer guarantee?

[Simon Urbanek]

Erez,

I think the API is very explicit about this, NULL is not an accepted input for any function taking SEXP by design. The special case of try*Eval() return values can be taken as a case where the resulting object is not actually SEXP but rather a special type which can be NULL (=failure) or SEXP. It may be even perhaps useful to declare it as a separate type to make this clearer, but I don't think it was really necessary so far. Any other cases where a SEXP value somehow escapes as NULL should be considered a bug.

Cheers,
Simon


> On 30/07/2024, at 2:54 PM, Erez Shomron <r-mails using erezsh.org> wrote:
> 
> Thank you Ivan,
> 
> At this point, without it being documented explicitly, I tend to lean on the safe side.
> 
> If the non-null assumption is ever incorrect, on debug and safe builds unwrapping is an assert that will guarantee to crash R.
> 
> While the source code has plenty of NULL checks, also for some SEXP, it's hard to tell just from grepping if any are related to the public API or not.
> 
> Secondly as zig's documentation indicates: "Edge cases matter". If I'm making bindings in this language, I should care about edge cases as well.
> 
> Last but not least, thanks for sharing your WIP documentation. If you agree, I definitely can use that as a reference as I progress.
> 
> Best regards,
> - Erez
> 
> 
> 
> On Mon, Jul 29, 2024, at 1:23 PM, Ivan Krylov wrote:
>> В Sat, 27 Jul 2024 14:36:20 +0300
>> "Erez Shomron" <r-mails using erezsh.org> пишет:
>> 
>>> I'm working on bindings for the API (for zig), and was wondering if
>>> the R's C API guarantees it won't return null pointers? The only
>>> reference I found in the "Writing R Extensions" manual where this not
>>> the case is `R_tryEval` and `R_tryEvalSilent`.
>> 
>> Based on what I've been reading while working on (still very much
>> incomplete) <https://aitap.codeberg.page/R-api>, I think that these are
>> the only two cases where a SEXP can be null, precisely because a null
>> pointer is distinguished from every possible value that could be
>> returned by eval().
>> 
>> Some APIs may accept a null SEXP (with comments in the source code that
>> this is to support some legacy code, not the intended use), but when R
>> wants to return a value, it is always allocated through the memory
>> manager. A failing allocation will longjmp() away from the frame, not
>> return a null pointer.
>> 
>> It's hard to prove a negative, though.
>> 
>> -- 
>> Best regards,
>> Ivan
>> 
> 
> ______________________________________________
> R-help using r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>