[R] C API - no NULL pointer guarantee?

[Erez Shomron]

Thank you and I appreciate the explanation.

I will drop the optional from all but the tryEval() cases.

Thanks,
- Erez



On Tue, Jul 30, 2024, at 8:32 AM, Simon Urbanek wrote:
> 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.
> > 
> 
>