[R-pkg-devel] Canonical way to Rprintf R_xlen_t

[Daniel Kelley]

I hope it's okay to ask this on the present thread, rather than starting a new one...

On this issue of the C format for various integer-type items, I am finding that checks made with devtools::check_win_devel() give different results than those made with the github R-CMD-check action named ubuntu-latest-devel.  Which (if either) might be best for someone trying to fix up code for a CRAN release?

# Details

The code

NumericVector a;
::R_error("size %ld", a.size());

does not lead to warnings with R-CMD-check/ubuntu-latest-devel compilation, but it does with devtools::check_win_devel().  And the reverse is true with the code

NumericVector a;
::R_error("size %lld", a.size());

so one of these two methods must not be a good way to know if I'm doing the right thing.  I don't want to submit an update to CRAN that will lead to problems there, so I am keen to find a way to test this aspect without making a new submission (and thereby wasting time for the kind folks who run CRAN).

Thanks.

Dan.

> On Nov 28, 2023, at 4:30 PM, Reed A. Cartwright <racartwright using gmail.com> wrote:
> 
> CAUTION: The Sender of this email is not from within Dalhousie.
> 
> If I have read the R's change log correctly, C99 printf format is now
> supported on Windows. I think the change was made in the last week.
> 
> On Tue, Nov 28, 2023, 13:01 Henrik Bengtsson <henrik.bengtsson using gmail.com>
> wrote:
> 
>> "%td" is not supported on all platforms/compilers.  This is what I got
>> when I added it to 'matrixStats';
>> 
>> * using log directory
>> 'D:/a/matrixStats/matrixStats/check/matrixStats.Rcheck'
>> * using R Under development (unstable) (2023-11-26 r85638 ucrt)
>> * using platform: x86_64-w64-mingw32
>> * R was compiled by
>> gcc.exe (GCC) 12.3.0
>> GNU Fortran (GCC) 12.3.0
>> * running under: Windows Server 2022 x64 (build 20348)
>> * using session charset: UTF-8
>> * using options '--no-manual --as-cran'
>> * checking for file 'matrixStats/DESCRIPTION' ... OK
>> * this is package 'matrixStats' version '1.1.0-9003'
>> * checking package namespace information ... OK
>> * checking package dependencies ... OK
>> * checking if this is a source package ... OK
>> * checking if there is a namespace ... OK
>> * checking for executable files ... OK
>> * checking for hidden files and directories ... OK
>> * checking for portable file names ... OK
>> * checking serialization versions ... OK
>> * checking whether package 'matrixStats' can be installed ... [22s] WARNING
>> Found the following significant warnings:
>> binCounts.c:25:81: warning: unknown conversion type character 't' in
>> format [-Wformat=]
>> binCounts.c:25:11: warning: too many arguments for format
>> [-Wformat-extra-args]
>> binMeans.c:26:60: warning: unknown conversion type character 't' in
>> format [-Wformat=]
>> binMeans.c:26:67: warning: unknown conversion type character 't' in
>> format [-Wformat=]
>> ...
>> See 'D:/a/matrixStats/matrixStats/check/matrixStats.Rcheck/00install.out'
>> for details.
>> * used C compiler: 'gcc.exe (GCC) 12.2.0'
>> 
>> It worked fine on Linux. Because of this, I resorted to the coercion
>> strategy, i.e. "%lld" and (long long int)value.  FWIW, on MS Windows,
>> I see 'ptrsize_t' being 'long long int', whereas on Linux I see 'long
>> int'.
>> 
>> /Henrik
>> 
>> On Tue, Nov 28, 2023 at 11:51 AM Ivan Krylov <krylov.r00t using gmail.com>
>> wrote:
>>> 
>>> On Wed, 29 Nov 2023 06:11:23 +1100
>>> Hugh Parsonage <hugh.parsonage using gmail.com> wrote:
>>> 
>>>> Rprintf("%lld", (long long) xlength(x));
>>> 
>>> This is fine. long longs are guaranteed to be at least 64 bits in size
>>> and are signed, just like lengths in R.
>>> 
>>>> Rprintf("%td, xlength(x));
>>> 
>>> Maybe if you cast it to ptrdiff_t first. Otherwise I would expect this
>>> to fail on an (increasingly rare) 32-bit system where R_xlen_t is int
>>> (which is an implementation detail).
>>> 
>>> In my opinion, ptrdiff_t is just the right type for array lengths if
>>> they have to be signed (which is useful for Fortran interoperability),
>>> so Rprintf("%td", (ptrdiff_t)xlength(x)) would be my preferred option
>>> for now. By definition of ptrdiff_t, you can be sure [*] that there
>>> won't be any vectors on your system longer than PTRDIFF_MAX.
>>> 
>>>> using the string macro found in Mr Kalibera's commit of r85641:
>>>> R_PRIdXLEN_T
>>> 
>>> I think this will be the best solution once we can afford
>>> having our packages depend on R >= 4.4.
>>> 
>>> --
>>> Best regards,
>>> Ivan
>>> 
>>> [*]
>> https://urldefense.com/v3/__https://en.cppreference.com/w/c/types/ptrdiff_t__;!!IKRxdwAv5BmarQ!Zm84sWjl9Vg2_hQ8e5geMYnVFH8eNO-9KZsIkE7Tjk_V_-tj8W2Ept9o43gl-WGDczLbJTORU0oHTnfSA5iTLmO_uTKw$
>> posits that there
>>> may exist long vectors that fit in SIZE_MAX (unsigned) elements but not
>>> PTRDIFF_MAX (signed) elements. If such vector exists, subtracting two
>>> pointers to its insides may result in undefined behaviour. This may be
>>> already possible in a 32-bit process on Linux running with a 3G
>>> user-space / 1G kernel-space split. The only way around the problem is
>>> to use unsigned types for lengths, but that would preclude Fortran
>>> compatibility.
>>> 
>>> ______________________________________________
>>> R-package-devel using r-project.org mailing list
>>> 
>> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-package-devel__;!!IKRxdwAv5BmarQ!Zm84sWjl9Vg2_hQ8e5geMYnVFH8eNO-9KZsIkE7Tjk_V_-tj8W2Ept9o43gl-WGDczLbJTORU0oHTnfSA5iTLmjE7gjq$
>> 
>> ______________________________________________
>> R-package-devel using r-project.org mailing list
>> 
>> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-package-devel__;!!IKRxdwAv5BmarQ!Zm84sWjl9Vg2_hQ8e5geMYnVFH8eNO-9KZsIkE7Tjk_V_-tj8W2Ept9o43gl-WGDczLbJTORU0oHTnfSA5iTLmjE7gjq$
>> 
> 
>        [[alternative HTML version deleted]]
> 
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel