From m@ech|er @end|ng |rom @t@t@m@th@ethz@ch  Sat Jan  8 16:36:26 2022
From: m@ech|er @end|ng |rom @t@t@m@th@ethz@ch (Martin Maechler)
Date: Sat, 8 Jan 2022 16:36:26 +0100
Subject: [Rd] "getOption(max.print) omitted %d entries" may be negative
In-Reply-To: <fe5e0663-1827-8045-7aee-6b87e9c140ac@gmail.com>
References: <CAJmOi+MFUrn+hx9PVj1ALWwMFPq518dTYGPDToqF92TB4w9xgw@mail.gmail.com>
 <25043.12072.659723.752755@stat.math.ethz.ch>
 <fe5e0663-1827-8045-7aee-6b87e9c140ac@gmail.com>
Message-ID: <25049.44922.461214.439279@stat.math.ethz.ch>

>>>>> Tomas Kalibera 
>>>>>     on Mon, 3 Jan 2022 20:59:30 +0100 writes:

    > 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

I have committed changes now (svn r81459), using %lld as mentioned above,
also including  trioremap.h  for Windows,
not just for printing long unnamed atomic vectors, but also in
the code for printing named vectors and "generic vectors" aka
lists.... which previously did not allow long vectors at all,
using `length() and `int` before.

I've set it as to be ported to  "R 4.1.2 patched" eventually.
Martin




    >> 
    >> [Please, C compiler / library standard experts, chime in
    >> !]
    >> 
    >> Martin Maechler ETH Zurich and R core team



[Rd] "getOption(max.print) omitted %d entries" may be negative
Martin Maechler