[R] C API - no NULL pointer guarantee?

[Erez Shomron]

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
>