R devel - Jan 2022 - "getOption(max.print) omitted %d entries" may be negative

>>>>> Hugh Parsonage 
>>>>>     on Wed, 29 Dec 2021 00:36:51 +1100 writes:
    > In src/main/printvector.c in the definition of printVector and
    > printNamedVector  (and elsewhere):

    > Rprintf(" [ reached getOption(\"max.print\") -- omitted
%d entries ]\n",
    >         n - n_pr);

    > Though n - n_pr is of type R_xlen_t so may not be representable as
    > int. In practice negative values may be observed for long vectors.

    > Rprintf(" [ reached getOption(\"max.print\") -- omitted
%lld entries ]\n",
    >         n - n_pr);


Thank you Hugh, for finding and reporting this,
including a proposed remedy. 

At some point in time, I think the   %lld   format specifier was
not portable enough to all versions of C compiler / libraries
that were considered valid for compiling R.

See e.g.,

   https://stackoverflow.com/questions/462345/format-specifier-for-long-long

which says that "it" does not work on Windows.

Maybe this has changed now that we require C99 and also that
since R version 4.0.0 (or 4.0.1) we also use a somewhat more
recent version of gcc also on Windows?

... ah, searching the R sources reveals uses of %lld
*plus*

#ifdef Win32
#include <trioremap.h> /* for %lld */
#endif

so it seems we can and should probably change this ...

[Please, C  compiler / library standard experts, chime in !]

Martin Maechler
ETH Zurich  and  R core team

On 1/3/22 6:15 PM, Martin Maechler wrote:
>>>>>> Hugh Parsonage
>>>>>>      on Wed, 29 Dec 2021 00:36:51 +1100 writes:
>      > In src/main/printvector.c in the definition of printVector and
>      > printNamedVector  (and elsewhere):
>
>      > Rprintf(" [ reached getOption(\"max.print\") --
omitted %d entries ]\n",
>      >         n - n_pr);
>
>      > Though n - n_pr is of type R_xlen_t so may not be representable
as
>      > int. In practice negative values may be observed for long
vectors.
>
>      > Rprintf(" [ reached getOption(\"max.print\") --
omitted %lld entries ]\n",
>      >         n - n_pr);
>
>
> Thank you Hugh, for finding and reporting this,
> including a proposed remedy.
>
> At some point in time, I think the   %lld   format specifier was
> not portable enough to all versions of C compiler / libraries
> that were considered valid for compiling R.
>
> See e.g.,
>
>    
https://stackoverflow.com/questions/462345/format-specifier-for-long-long
>
> which says that "it" does not work on Windows.
>
> Maybe this has changed now that we require C99 and also that
> since R version 4.0.0 (or 4.0.1) we also use a somewhat more
> recent version of gcc also on Windows?
>
> ... ah, searching the R sources reveals uses of %lld
> *plus*
>
> #ifdef Win32
> #include <trioremap.h> /* for %lld */
> #endif
>
> so it seems we can and should probably change this ...
UCRT on Windows supports the C99 format, so %lld works, but there is a 
bug in GCC which causes a compilation warning to appear for %lld.

There is an open GCC bug report with a patch. It has not been adopted, 
yet, but I got reviews from two people and patched the build of GCC in 
Rtools42. So, %lld etc now works without a warning for us on Windows and 
certainly can be used in package code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130

For base R, as we have been using the trio remap to get rid of the 
warning with %lld, it would make sense to keep doing this for 
consistency. Eventually we might be able to remove the dependency on 
trio, after checking that the other problems due to which we use it have 
been resolved in UCRT.

Tomas
>
> [Please, C  compiler / library standard experts, chime in !]
>
> Martin Maechler
> ETH Zurich  and  R core team
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel