[Rd] Error generated by .Internal(nchar) disappears when debugging

[Duncan Murdoch]

On 05/10/2015 8:25 PM, Matt Dowle wrote:
> 
> On Mon, Oct 5, 2015 at 4:57 PM, 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.
> 
>     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.
> 
>     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.
> 
>     Duncan Murdoch
> 
> 
> I don't have Windows so am not able to test unfortunately.
> data.table makes no calls to .Internal(). Such calls are caught and
> prevented by R CMD check.
> Both data.table and copula contain "ByteCompile: yes" in their
> DESCRIPTION files.  Does the toy package break with that setting?
> Matt
> 

That's it.  With "ByteCompile: yes" I get the same error.

I don't know if there's anything we can do about this now, but we should
be able to avoid it in the future.

Duncan Murdoch