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 at 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
>