[Rd] Error generated by .Internal(nchar) disappears when debugging
murdoch.duncan at gmail.com
Tue Oct 6 15:02:57 CEST 2015
On 06/10/2015 8:48 AM, Joris Meys wrote:
> On Tue, Oct 6, 2015 at 1:57 AM, Duncan Murdoch <murdoch.duncan at gmail.com
> <mailto:murdoch.duncan at gmail.com>> wrote:
> On 05/10/2015 7:24 PM, Matt Dowle wrote:
> > Joris Meys <jorismeys <at> gmail.com <http://gmail.com>> writes:
> >> Hi all,
> >> I have a puzzling problem related to nchar. In R 3.2.1, the internal
> > nchar
> >> gained an extra argument (see
> >> https://stat.ethz.ch/pipermail/r-announce/2015/000586.html)
> >> I've been testing code using the package copula, and at home I'm still
> >> running R 3.2.0 (I know, I know...). When trying the following code, I
> > got
> >> an error:
> >>> library(copula)
> >>> fgmCopula(0.8)
> >> Error in substr(sc[i], 2, nchar(sc[i]) - 1) :
> >> 4 arguments passed to .Internal(nchar) which requires 3
> >> Cheers
> >> Joris
> > I'm seeing a similar problem. IIUC, the Windows binary .zip from CRAN of
> > any package using base::nchar is affected. Could someone check my answer
> > here is correct please : http://stackoverflow.com/a/32959306/403310
> Nobody has posted a simple reproducible example here, so it's kind of
> hard to say.
> You're free to try the simple reproducible example I've provided in my
> original question. Tried that out on 3 different computers, and I got
> the same behaviour 3 times.
As I posted yesterday, with Matt's help I was able to find a simple
reproduction of the bug.
The reason I wouldn't count your original post as a simple reproducible
example (and the same applies to what I saw on Stack Overflow), was that
it required a fairly large package (copula) in the demonstration. I'm
not familiar with the internals of that package (or Matt's package
discussed on Stack Overflow), so it would be a lot of work for me to
identify what it was in them that triggered the bug. If the bug had
required those packages and couldn't be demonstrated without them, then
it would likely be a bug in those packages, not in R.
> I would have guessed that a change to the internal signature of the C
> code underlying nchar() wouldn't have any effect on a package that
> called the R nchar() function.
> When I put together my own example (a tiny package containing a function
> calling nchar(), built to .zip using R 3.2.2, installed into R 3.2.0),
> it confirmed my guess.
> On the other hand, if some package is calling the .Internal function
> directly, I'd expect that to break. Packages shouldn't do that.
> I never said the package called the internal function, because it
> doesn't. The error message reports there's an error insubstr(sc[i], 2,
> nchar(sc[i]) - 1). Then it continues to indicate the problem occurs at
> the moment nchar() calles the internal function. That's how the core
> team wrote the nchar() function.
> So I'd say there's been no evidence posted of a problem in R here,
> though there may be problems in some of the packages involved. I'd
> welcome an example that provided some usable evidence.
> With all due respect for your involvement in and knowledge about R, I
> have the impression you read too quickly through the mail. There is a
> problem and it is reproducible. I'm just not smart enough to figure out
> how the problem came about.
I sometimes do read too quickly and miss important details, but I don't
think I did in this case.
More information about the R-devel