Data.table: rchk messages 1.11.4

[mattdowle]

I still didn't get them all in #2865 (fmelt.c and reorder.c). I asked @kalibera about the reorder.c one, he kindly had a look and spotted the problem in it (a true positive). The fmelt.c ones are probably due to my changes to fmelt in #2865 without rerunning rchk to check. I can probably solve those but haven't looked yet.
I've almost managed to install and run rchk myself locally. Current issue https://github.com/kalibera/rchk/issues/10.

Yesterday's rchk output just mentioned reorder.c and fmelt.c. It checked 1.11.4 under R-devel. So it's possible a change in R-devel yesterday caused the extra warnings today. I had thought it might be that Tomas is making rchk stricter, but I asked and it's not that. Depending on the structure and complexity of the code, rchk can stop early after reporting a set of warnings. So when you fix them, you really need to rerun rchk repeatedly until they are all ironed out. Hence I'm installing rchk locally.

Package data.table version 1.11.4
Package built using 74804/R 3.6.0; x86_64-pc-linux-gnu; 2018-05-30 15:58:55 UTC; unix   
Checked with rchk version 3d43fe28045c41944a28afb89478b9891808dd42
More information at https://github.com/kalibera/cran-checks/blob/master/rchk/PROTECT.md

Function chmatch2_old
  [UP] calling allocating function unlist2(V) with a fresh pointer (l <arg 1>) data.table/src/rbindlist.c:825

Function fmelt
  [UP] unprotected variable dtnames while calling allocating function Rf_allocVector data.table/src/fmelt.c:663
  [UP] unprotected variable dtnames while calling allocating function preprocess(?,?,?,V,V,?,?,?) data.table/src/fmelt.c:664
  [UP] allocating function getvaluecols may destroy its unprotected argument (dtnames <arg 2>), which is later used. data.table/src/fmelt.c:670
  [UP] calling allocating function getvaluecols with a fresh pointer (dtnames <arg 2>) data.table/src/fmelt.c:670
  [UP] allocating function getvarcols may destroy its unprotected argument (dtnames <arg 2>), which is later used. data.table/src/fmelt.c:671
  [UP] calling allocating function getvarcols with a fresh pointer (dtnames <arg 2>) data.table/src/fmelt.c:671
  [UP] allocating function getidcols may destroy its unprotected argument (dtnames <arg 2>), which is later used. data.table/src/fmelt.c:672
  [UP] unprotected variable dtnames while calling allocating function Rf_allocVector data.table/src/fmelt.c:675
  [UP] unprotected variable dtnames while calling allocating function Rf_allocVector data.table/src/fmelt.c:684

Function gmax
  [UP] calling allocating function Rf_coerceVector(V,?) with a fresh pointer (ans <arg 1>) data.table/src/gsumm.c:391

Function gmin
  [UP] calling allocating function Rf_coerceVector(V,?) with a fresh pointer (ans <arg 1>) data.table/src/gsumm.c:260

Function reorder
  [PB] has possible protection stack imbalance data.table/src/reorder.c:109

Function setselfref
  [UP] calling allocating function R_MakeExternalPtr with argument allocated using Rf_getAttrib(?,S:names) data.table/src/assign.c:36

Function userOverride
  [UP] calling allocating function chmatch(?,V,?,?) with argument allocated using Rf_getAttrib(?,S:names) data.table/src/freadR.c:227

[kalibera]

Errors related to names, obtained from "names" attribute of an object, are often benign: rchk often cannot tell that the base object is of such type that the names will not be allocated. It is, however, much cleaner and recommended to protect such names, because R internals may change and also because sometimes it is impossible to tell even for a human that for sure say a pairlist-based object would not be used. One should always treat the return value of getAttrib as a fresh object.

[kalibera]

Errors reported in gsumm.c are real errors - ans needs to be protected.

[kalibera]

The error reported in rbindlist.c is also a real error. l has to be protected. As a general rule, all arguments must be protected by the caller (explicitly or implicitly) when passed to a function. Specifically here it is really necessary, l could be destroyed by allocations inside unlist2.

[mattdowle]

These were fixed here: https://github.com/Rdatatable/data.table/pull/3033
Thanks @kalibera ! I ran rchk locally and I believe it's clear now. This will be confirmed or not when rchk runs on 1.11.6 which has today been accepted on CRAN.