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.dun...@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@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
