Do you happen to have suitable hardware to test this? It could well be thatmax now fails too. We could cheat and just merge and let@jeroen's builders take the discovery brunt. (Or we could add a new CI action...)

No, I don't. There's a Mac at home that I could borrow, but unfortunately it's Intel.

We'll find a creative solution.

@Enchufa2 note that this test is not executed for the "release" versions of Rcpp, but only for thex.x.x.x versions so that is why the problem did not surface on CRAN or Debian arm64 machines either. But it has always been there.

I have confirmed manually that when we forceRunAllRcppTests=TRUE then also the CRAN release fails.

Looks like this worked with an additional CI runner for macOS. Yay. (And thanks for the suggestion earlier,@jeroen)

@jeroen Yes, I noted that. I was referring to line 1574, which has a similar test but withintmax instead ofintmin, and the build log at r-universe reports no ERROR for that one.

Don't we die immediately? So it may not get to that line?

AFAIK, unless the session aborts or something, everything runs. E.g., put the following into a test file:

library(tinytest)expect_true(FALSE)expect_true(TRUE)expect_true(FALSE)

Then:

$ Rscript -e'tinytest::run_test_file("test.R")'test.R........................    3 tests 2 fails 25ms----- FAILED[data]: test.R<2--2> call| expect_true(FALSE) diff| Expected TRUE, got FALSE ----- FAILED[data]: test.R<4--4> call| expect_true(FALSE) diff| Expected TRUE, got FALSE Showing 2 out of 3 results: 2 fails, 1 passes (25ms)

Yes you are correct. I think I confused myself mentally comparing with "another popular flavour" for unit tests which we still use in another package that keeps me busy at work.

Looking at the sugar code, we try to castR_PosInf to the appropriate storage type here:

Distilling this into a smaller example, I used:

#include <Rcpp.h>using namespace Rcpp;// [[Rcpp::export]]SEXP casting_test() {    int value = static_cast<int>(R_PosInf);    return Rf_ScalarInteger(value);}/*** Rcasting_test()*/

On my ARM macOS machine:

$ R -s -e 'Rcpp::sourceCpp("abc.cpp")'> casting_test()[1] 2147483647

And on an x86_64 Docker image:

root@f00a2fde26d3:~/scratch# R -s -e 'Rcpp::sourceCpp("test.cpp")'> casting_test()[1] NA

And some StackOverflow searching suggests that attempting to castINFINITY to an integer is undefined behavior, e.g.https://stackoverflow.com/questions/38795544/is-casting-of-infinity-to-integer-undefined.

To wit -- should we just returnNA here? (if the storage type is notdouble)

Yes. That seems like a bit of logic error / thinko given

>Inf      [1]Inf> as.integer(Inf) [1]NAWarningmessage:NAsintroducedbycoerciontointegerrange>

Should we warn just like R does here?

Perhaps... I'm not sure how closely we try to model the base R equivalents in the sugar functions.

It is a little awkward for us thatmin(integer()) returnsInf, which is adouble value, whereas our sugar functions try to preserve the same type. So we're forced to diverge a bit no matter what.

> class(min(integer()))[1] "numeric"Warning message:In min(integer()) : no non-missing arguments to min; returning Inf

Hoh boy. Isn'tmin(integer()) == Inf a bug? Maybe-Inf ? Hm.