-Wformat warning from `include/Rcpp/date_datetime/date_datetime.h:29`

[pjonsson]

I enabled some more warnings when compiling a package that uses Rcpp and got this warning which seems to be caused by Rcpp itself:

In file included from /usr/local/lib/R/site-library/Rcpp/include/Rcpp/date_datetime/date_datetime.h:29:
/usr/local/lib/R/site-library/Rcpp/include/Rcpp/date_datetime/Datetime.h:83:65: warning: format specifies type 'int' but the argument has type 'unsigned int' [-Wformat]
   83 |                 res = ::snprintf(txtsec, 63, "%s.%06d", txtiso, m_us);
      |                                                  ~~~~           ^~~~
      |                                                  %06u

It probably doesn't make any practical difference for the result, but it's nice if Rcpp itself doesn't trigger common compiler warnings.

[eddelbuettel]

That sounds plausible but I cannot reproduce it, and I use -pedantic -Wformat options.

Code

#include <Rcpp/Lightest>

// [[Rcpp::export]]
void foo() {
  unsigned int v = 42;
  printf("%06d\n", v);
}

/*** R
foo()
*/

Output (in verbose mode)

edd@paul:~$ Rscript -e 'Rcpp::sourceCpp("/tmp/r/foo.cpp", verbose=TRUE)'

Generated extern "C" functions 
--------------------------------------------------------


#include <Rcpp.h>
#ifdef RCPP_USE_GLOBAL_ROSTREAM
Rcpp::Rostream<true>&  Rcpp::Rcout = Rcpp::Rcpp_cout_get();
Rcpp::Rostream<false>& Rcpp::Rcerr = Rcpp::Rcpp_cerr_get();
#endif

// foo
void foo();
RcppExport SEXP sourceCpp_1_foo() {
BEGIN_RCPP
    Rcpp::RNGScope rcpp_rngScope_gen;
    foo();
    return R_NilValue;
END_RCPP
}

Generated R functions 
-------------------------------------------------------

`.sourceCpp_1_DLLInfo` <- dyn.load('/tmp/r/RtmpQ78SQk/sourceCpp-x86_64-pc-linux-gnu-1.1.1.1/sourcecpp_1299deb94af4e/sourceCpp_2.so')

foo <- Rcpp:::sourceCppFunction(function() {}, TRUE, `.sourceCpp_1_DLLInfo`, 'sourceCpp_1_foo')

rm(`.sourceCpp_1_DLLInfo`)

Building shared library
--------------------------------------------------------

DIR: /tmp/r/RtmpQ78SQk/sourceCpp-x86_64-pc-linux-gnu-1.1.1.1/sourcecpp_1299deb94af4e

/usr/lib/R/bin/R CMD SHLIB -o 'sourceCpp_2.so' 'foo.cpp' 
using C++ compiler: ‘g++ (Ubuntu 15.2.0-4ubuntu4) 15.2.0’
g++ -I"/usr/share/R/include" -DNDEBUG   -I"/usr/local/lib/R/site-library/Rcpp/include" -I"/tmp/r"     -fpic  -O3 -Wall -pipe -pedantic -Wformat -Wformat-security -Wno-parentheses -Wno-nonnull -Wno-ignored-attributes -Wno-unused-function    -c foo.cpp -o foo.o
g++ -Wl,-S -shared -L/usr/lib/R/lib -Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -Wl,-z,relro -o sourceCpp_2.so foo.o -L/usr/lib/R/lib -lR

> foo()
000042
edd@paul:~$ 

What is your compiler, and what flags do you use?

[eddelbuettel]

The (with a laugh 😜 ) re-state the obvious, the flags "that matter" are the ones CRAN dings us for, and in this case it may just be that you dialed up strictness one level higher they (and us) do.

[pjonsson]

Thank you for taking a look. I'm using the clang-20 package in Ubuntu 24.04.

And you're right that I added the -Wformat to PKG_CPPFLAGS in Makevars.in in that package (trying to track down an issue). If it's just the default compilation flags that are supported I'll close this issue, sorry about the noise.

[eddelbuettel]

Still cannot reproduce with what I currently use -- clang-21 as that is what CRAN nags us with issues. Maybe clang is now less picky here and 'just does the right thing' between an unsigned int and an int format? I agree that there is probably little here so thanks for closing it.

[kevinushey]

FWIW, given that m_us really is an unsigned int, we should be using %u rather than %d in the format specifier. (Or, casting to int when we provide the argument to snprintf.)

[eddelbuettel]

I agree with that, but I was also curious how I had never seen the warning :-/ I guess one needs to hit the snprintf().

[eddelbuettel]

Yes, and we cast int to it and assign NA_INTEGER which is all nonsense. I will clean that up.