Surprising behavior with return values

[wch]

I'm writing a function that returns integers, and I want it to return 0 or integers(0) as a sentinel value in case of an error. However, when I tried doing that, I ran into some surprising behavior.

My first attempt was to return a bare int, which resulted in a segfault. I discovered later that int doesn't automatically get coerced to integer. The only reason this was allowed to compile is because 0 has a special meaning; when I tried using 1, it resulted in a compile-time error -- which would have been useful for 0 as well.

cpp11::cpp_function("
integers test() {
  return 0;
}")
test()
#>  *** caught segfault ***
#> address 0x0, cause 'memory not mapped'

I tried returning integers(0) and got a segfault, which again was surprising:

cpp11::cpp_function("
integers test() {
  return integers(0);
}")
test()
#>  *** caught segfault ***
#> address 0x0, cause 'memory not mapped'

Then I tried integers(), and got NULL, but I would have expected integer(0):

cpp11::cpp_function("
integers test() {
  return integers();
}")
test()
#> NULL

Then I tried writable::integers(0) but got a compilation error:

cpp11::cpp_function("
integers test() {
  return writable::integers(0);
}")
#> (Compile error)

Then I tried writable::integers() but got an error when running the function:

cpp11::cpp_function("
integers test() {
  return writable::integers();
}")
test()
#> Error: Invalid input type, expected 'integer' actual 'NULL'

So my immediate question is, is there a one-liner to return either a 0 or zero-length integer vector from this function? (And note that the function signature is integer instead of int because in most cases I return a vector.)

The bigger questions are:

• Can there be better compile-type checks to prevent the segfault code from compiling?
• Why does returning integers(0) result in a segfault?
• Why does returning integers() result in NULL, and returning writable::integers() result an error where it expects integer but gets NULL?

[jimhester]

You need to disambiguate which constructor you want to call. e.g. the writable vec†or classes all take a classname(R_xlen_t) constructor which is used to allocate a vector of the specified class with the given size. They also take a constructor with an initializer list for the value type the vector holds, in this case an integer. Because 0 could be either a R_xlen_t or an int the compiler does not know which to use, so you have to specify it.

cpp11::cpp_source(code = "#include <cpp11.hpp>

[[cpp11::register]]
int int_1() {
  return 1;
}

[[cpp11::register]]
int int_0() {
  return 0;
}

[[cpp11::register]]
cpp11::integers integers_0() {
  return cpp11::writable::integers(R_xlen_t(0));
}

[[cpp11::register]]
cpp11::integers integers_00() {
  return cpp11::writable::integers({0});
}
")

int_1()
#> [1] 1

int_0()
#> [1] 0

integers_0()
#> integer(0)

integers_00()
#> [1] 0

^{Created on 2021-03-26 by the reprex package (v1.0.0)}

As to the segfaults the 0 is being implicitly converted to a SEXP and the pointer is then being deferrenced by R. It is possible we could make these constructors explicit to avoid this, though that will disable implicit casts from cpp11::sexp, which packages may already be depending on.

The reason the default constructor returns NULL is because the default constructors are guaranteed to perform no allocations and never throw exceptions, so it cannot create a zero length vector. This is an important property to retain as some container classes cannot support default constructors that may throw exceptions. Therefore the internal data_ pointer is always initially set to R_NilValue.

[wch]

This may be a really basic question, but why is it important for default constructors to not allocate or throw? The default constructor behavior I would expect for a vector-like object is that it creates a zero-length vector.

Thanks for the explanations -- now I understand the technical reasons for the current behavior, but it's still confusing from a user perspective. :) It would be nice if there was something like a cookbook in the website with information on how to do basic tasks like this.

[jimhester]

Basically the reasons mentioned in https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rc-default00. If we use the R allocator in a default constructor it may fail to allocate, which means we must throw an exception via unwind protect.

Yes, I agree a cookbook would be great. It is one of the things the cpp11 intern this spring is going to be working on.