[R-pkg-devel] handling of byte-order-mark on r-devel-linux-x86_64-debian-clang machine

[Daniel Kelley]

In the most recent release of the oce package, there is a new test that uses a package-supplied file of meteorological data.  This is one of three such files that are included with the package.  They are from Environment Canada, which keeps changing the format, and so oce needs to be able to read all three varieties.  In the test, I check whether the column names as read match my expectation.

This file starts with a byte-order-mark, and this is skipped over on all but the r-devel-linux-x86_64-debian-clang machine (and, I think, one or both of the Windows machines, but I have the test turned off on those machines, for that reason).

I don't like to see errors in the CRAN page (https://cran.r-project.org/web/checks/check_results_oce.html) but I also don't like making oce releases with just a few days of separation.  What ought I to do?

I'm just guessing, since I don't have access to any test machine (and rhub never seems to be up-to-date with the CRAN test machines), but this seems like a bug in the r-devel-linux-x86_64-debian-clang test setup.  Things are fine on r-devel-linux-x86_64-debian-gcc, so it seems to be a clang (vs gcc) problem.  And things are fine on r-devel-linux-x86_64-fedora-clang, which has clang 14.0.0 (vs clang 14.0.1 on r-devel-linux-x86_64-debian-gcc).

As for the problem itself, it seems like a bug to me because I thought the whole point of a byte-order-mark was that software should take note of it, but then discard it.  Otherwise, taking this particular case, R users could not rely on things like scan(), read.table(), and so forth, to read data properly.  Basically, every user would have to contend with this endianness issue in their code, instead of letting the system handle it.

I'm sorry this email is so long.  Long story short: should I re-release a biggish R package a few days after a release, to fix a bug on one test machine that might not even be a bug?  (I mention "biggish" because oce fails the time-to-build test, and so releasing it is tricky and wastes time for folks on CRAN.)

Thanks in advance for any advice.

Dan Kelley / Department of Oceanography / Dalhousie University / Canada