From |kry|ov @end|ng |rom d|@root@org  Mon Feb  5 22:01:11 2024
From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov)
Date: Tue, 6 Feb 2024 00:01:11 +0300
Subject: [Rd] Advice debugging M1Mac check errors
In-Reply-To: <CAFDswJu2aDQzCZHJT7RqyBP-J8DLcj6PLzRBHbcStfxBJvw5Mg@mail.gmail.com>
References: <CAFDswJu2aDQzCZHJT7RqyBP-J8DLcj6PLzRBHbcStfxBJvw5Mg@mail.gmail.com>
Message-ID: <20240206000111.07ada026@Tarkus>

On Sun, 4 Feb 2024 20:41:51 +0100
Holger Hoefling <hhoeflin at gmail.com> wrote:

> I wanted to ask if people have good advice on how to debug M1Mac
> package check errors when you don?t have a Mac?

Apologies for not answering the question you asked, but is this about
hdf5r and problems printing R_xlen_t [*] that appeared in 1.3.8 and you
tried to solve in 1.3.9?

We had a thread about this last November:
https://stat.ethz.ch/pipermail/r-package-devel/2023q4/010123.html

To summarise, there is no single standard C format specifier that can be
used to print R_xlen_t. As an implementation detail, it can be defined
as int or ptrdiff_t (or something completely different in the future),
and ptrdiff_t itself is usually defined as long or long long (or, also,
something completely different on a weirder platform). All three basic
types can have different widths and cause painful stack-related
problems when a mismatch happens.

In R-4.4, there will be a macro R_PRIdXLEN_T defining a compatible
printf specifier. Until then (and for compatibility with R-4.3 and
lower), it's relatively safe to cast to (long long) or (ptrdiff_t) and
then use the corresponding specifier, but that's not 100% future-proof.
Also, mind the warnings that mingw compilers sometimes emit for "new"
printf specifiers despite UCRT is documented to support them.

-- 
Best regards,
Ivan

[*] https://www.stats.ox.ac.uk/pub/bdr/M1mac/hdf5r.out



[Rd] Advice debugging M1Mac check errors
Ivan Krylov