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

[Michael Weylandt]

Doesn't the byte-compiler inline calls like nchar() to call the .Internal directly for certain optimization levels?  If the 'internal' signature changed in a point release, I'd expect an issue like the below.  (I'm pretty sure CRAN packages are byte-compiled at build-time, but don't use Windows so can't confirm)

To Joris' initial question. I think the debug machinery calls the unoptimized (no-inline) function. 

Michael

> On Oct 5, 2015, at 6:57 PM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote:
> 
>> On 05/10/2015 7:24 PM, Matt Dowle wrote:
>> Joris Meys <jorismeys <at> 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
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel