Behavior change in `cpp11::warning(fmt, args...)` between 0.5.3 and 0.5.4 (clang only)

[jennybc]

readxl built against cpp11 0.5.4 segfaults at runtime when emitting a coercion warning. Built against cpp11 0.5.3 (same readxl source, same R,same compiler), it works. Demo below.

In readxl:

• Issue: Segfault on MacOS tidyverse/readxl#784
• PR with workaround: Avoid cpp11::warning / cpp11::stop variadic forwarding tidyverse/readxl#785
  • Replaces cpp11::warning(fmt, args...) / cpp11::stop(fmt, args...) with helpers that pre-format the message into a std::string — bypassing cpp11's variadic-template forwarding entirely.

Problem observed in various settings:

• r-universe (segfault; this was the first tipoff — see linked readxl issue).
• CRAN: r-devel-linux-x86_64-{debian,fedora}-clang (segfault); r-release-macos-x86_64 (segfault);
  Additional checks on M1Mac (different presentation, but CRAN and I both think likely has same root cause). https://cran.r-project.org/web/checks/check_results_readxl.html. I also have an email from BDR and a May 15 deadline to fix.
• GHA: macos-latest (indefinite hang during vignette build, similar to CRAN M1Mac observation). Example: https://github.com/tidyverse/readxl/actions/runs/25193092291.
• Local: macOS arm64, Apple clang 21.

Not reproduced on gcc anywhere (CRAN's gcc flavors and Linux/Windows GHA all pass). Not R-version-specific: R 4.5 and R 4.6 both crash with cpp11 0.5.4.

Demo notes:

• R 4.5 on any clang platform. (cpp11 0.5.3 doesn't compile against R 4.6 —
  uses removed R_NamespaceRegistry — so R 4.5 is just where both versions
  build.)
• readxl pinned to v1.4.5 (current CRAN release, predates the workaround).
  cpp11 is header-only, so the buggy templates are baked into readxl.so at
  install time; rebuild from source for each cpp11 version.
• Build with -g -O0 for a clean, immediate segfault. At default -O2 the
  failure mode varies on macOS (indefinite hang). My ~/.R/Makevars:

CFLAGS=-g -O0 -Wall
CXXFLAGS=-g -O0 -Wall
CXX11FLAGS=-g -O0 -Wall
CXX14FLAGS=-g -O0 -Wall
CXX17FLAGS=-g -O0 -Wall
F77=gfortran
FC=gfortran

Here are the two different setups. It's important to specify ?source?reinstall in these pak calls to force recompilation and pick up the ambient cpp11.

# --- cpp11 0.5.3 ---
pak::pkg_install("cpp11@0.5.3")
pak::pkg_install("tidyverse/readxl@v1.4.5?source&reinstall")

# --- cpp11 0.5.4 ---
pak::pkg_install("cpp11")  # 0.5.4 from CRAN
pak::pkg_install("tidyverse/readxl@v1.4.5?source&reinstall")

This tickles the problem because we'll see some coercion warnings from forcing things to become logical.

library(readxl)

R.version.string
packageVersion("cpp11")
packageVersion("readxl")

read_excel(
  readxl_example("type-me.xlsx"),
  sheet = "logical_coercion",
  col_types = c("logical", "skip")
)

With cpp11 4.5.3, all is well. Notice the coercion warnings.

library(readxl)

R.version.string
#> [1] "R version 4.5.3 (2026-03-11)"
packageVersion("cpp11")
#> [1] '0.5.3'
packageVersion("readxl")
#> [1] '1.4.5'

read_excel(
  readxl_example("type-me.xlsx"),
  sheet = "logical_coercion",
  col_types = c("logical", "skip")
)
#> Warning: Expecting logical in A5 / R5C1: got a date
#> Warning: Expecting logical in A8 / R8C1: got 'cabbage'
#> # A tibble: 10 × 1
#>    `maybe boolean?`
#>    <lgl>
#>  1 NA
#>  2 FALSE
#>  3 TRUE
#>  4 NA
#>  5 TRUE
#>  6 FALSE
#>  7 NA
#>  8 TRUE
#>  9 FALSE
#> 10 FALSE

With cpp11 0.5.4, we see a segfault:

> library(readxl)
>
> R.version.string
[1] "R version 4.5.3 (2026-03-11)"
> packageVersion("cpp11")
[1] '0.5.4'
> packageVersion("readxl")
[1] '1.4.5'
> read_excel(
+   readxl_example("type-me.xlsx"),
+   sheet = "logical_coercion",
+   col_types = c("logical", "skip")
+ )

 *** caught segfault ***
address 0xffff11000000, cause 'invalid permissions'

Traceback:
 1: read_fun(path = path, sheet_i = sheet, limits = limits, shim = shim,     col_names = col_names, col_types = col_types, na = na, trim_ws = trim_ws,     guess_max = guess_max, progress = progress)
 2: tibble::as_tibble(l, .name_repair = .name_repair)
 3: set_readxl_names(read_fun(path = path, sheet_i = sheet, limits = limits,     shim = shim, col_names = col_names, col_types = col_types,     na = na, trim_ws = trim_ws, guess_max = guess_max, progress = progress),     .name_repair = .name_repair)
 4: read_excel_(path = path, sheet = sheet, range = range, col_names = col_names,     col_types = col_types, na = na, trim_ws = trim_ws, skip = skip,     n_max = n_max, guess_max = guess_max, progress = progress,     .name_repair = .name_repair, format = format)
 5: read_excel(readxl_example("type-me.xlsx"), sheet = "logical_coercion",     col_types = c("logical", "skip"))

[jennybc]

lldb backtrace from the crashing R (locally, macOS arm64, Apple clang 21, readxl built with -g -O0). Key frames:

* thread #1, stop reason = EXC_BAD_ACCESS (code=1, address=0xffff01000000)
  * frame #0: __tuple_leaf<0, SEXPREC*&, false>::get(this=0x0000ffff01000000)        at tuple:383
    frame #1: std::get<0>(tuple<SEXPREC*&, char const*&, char const*&>&&)            at tuple:1088
    frame #2: cpp11::detail::apply<void(SEXPREC*, char const*, ...), ...>(f, a=size=3, ...)   at protect.hpp:119
    frame #3: cpp11::detail::apply<void(SEXPREC*, char const*, ...), ...>(f, a=size=3)        at protect.hpp:125
    frame #4: cpp11::detail::closure<void(SEXPREC*, char const*, ...), ...>::operator()()     at protect.hpp:138
    frame #5-7: cpp11::unwind_protect<...>(...)                                               at protect.hpp:54-79
    frame #8: libR.dylib`R_UnwindProtect                                                      at context.c:984
    frame #11: cpp11::protect::function<...>::operator()<...>(...)                            at protect.hpp:152
    frame #12: cpp11::warning<char const*>(fmt="Expecting logical in %s: got a date",
                                           args="A5 / R5C1")                                  at protect.hpp:228
    frame #13: SheetView<Xlsx>::readCols(...)                                                 at SheetView.h:182

[jennybc]

Some prior history:

• Should cpp11::stop just throw an exception rather than using unwind_protect? #219: "Should cpp11::stop just throw an exception rather than using unwind_protect?" — I hit a bus error calling cpp11::stop() in a readxl constructor; demo at cpp11 stop in constructor DO NOT MERGE tidyverse/readxl#690 ("cpp11 stop in constructor DO NOT MERGE"). Only failed on macOS at the time.
• cpp11::warning(const char*) crashes but cpp11::warning(const std::string&) does not #295 (2022, closed as inactionable): "cpp11::warning(const char*) crashes but cpp11::warning(const std::string&) does not" — same crash signature as this one (std::tuple::get()), same template machinery, only with the const char* overload going through safe[Rf_warningcall]. Reporter (paleolimbot, on Arrow) noted that safe[Rf_warningcall](R_NilValue, "...") directly did not crash.

There's also a readxl-source artifact: src/XlsWorkBook.h and src/XlsCellSet.h use Rf_errorcall(R_NilValue, …) directly rather than cpp11::stop(…), precisely because of #219. So readxl has been working around this trickiness in spots for a few years.

• https://github.com/tidyverse/readxl/blame/c619224170ac6880e38ef986b095f431ad7a573d/src/XlsWorkBook.h#L39-L44
• https://github.com/tidyverse/readxl/blame/c619224170ac6880e38ef986b095f431ad7a573d/src/XlsCellSet.h#L47-L52
• https://github.com/tidyverse/readxl/blame/c619224170ac6880e38ef986b095f431ad7a573d/src/XlsCellSet.h#L63-L69