dec argument of fread() doesn't validate against NA_character_

[mcol]

This call produces an error:

fread(input = "whatever.csv", dec = NA_character_)

# Error in if (dec == "auto") dec = "" else stopifnot(nchar(dec) == 1L) :
#   missing value where TRUE/FALSE needed

# Output of sessionInfo()

R version 4.6.0 (2026-04-24)
Platform: x86_64-pc-linux-gnu
Running under: Ubuntu 24.04.4 LTS

Matrix products: default
BLAS:   /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.12.0
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.12.0  LAPACK version 3.12.0

locale:
 [1] LC_CTYPE=C.UTF-8       LC_NUMERIC=C           LC_TIME=C.UTF-8
 [4] LC_COLLATE=C.UTF-8     LC_MONETARY=C.UTF-8    LC_MESSAGES=C.UTF-8
 [7] LC_PAPER=C.UTF-8       LC_NAME=C              LC_ADDRESS=C
[10] LC_TELEPHONE=C         LC_MEASUREMENT=C.UTF-8 LC_IDENTIFICATION=C

time zone: Europe/Berlin
tzcode source: system (glibc)

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

other attached packages:
[1] data.table_1.18.2.1

loaded via a namespace (and not attached):
[1] compiler_4.6.0

I found this via the CBTF package (what's shown is the call minimized post-hoc):

library(CBTF)
fuzz("fread", package = "data.table",
      args = list(..input = "whatever.csv", dec = "auto"),
      what = test_inputs("na"))

 Fuzzing 1 function with 4 inputs (using 2 daemons)
ℹ 4 tests run  [20ms]
✖  🚨   CAUGHT BY THE FUZZ!   🚨

── Test input [[1]]: input = "R/file.R", dec = NA_real_
 fread  FAIL  is.character(dec) is not TRUE

── Test input [[2]]: input = "R/file.R", dec = NA_integer_
 fread  FAIL  is.character(dec) is not TRUE

── Test input [[3]]: input = "R/file.R", dec = NA_character_
 fread  FAIL  missing value where TRUE/FALSE needed

── Test input [[4]]: input = "R/file.R", dec = NA
 fread  FAIL  is.character(dec) is not TRUE

 [ FAIL 4 | WARN 0 | SKIP 0 | OK 0 ]

So 3 out of the 4 failures are false positive, but the NA_character_ case is unhandled.

[MichaelChirico]

In general I don't find this kind of bug compelling. If you actually encounter a weird error in practice, that's fine, but fuzzing input is best when it finds crashes, not just a confusing error (there's no actual person confused).