Prof Brian Ripley wrote: > On Fri, 25 Jan 2008, [EMAIL PROTECTED] wrote: > >> In R 2.6.1, a couple of places (discovered using valgrind) where the >> requested size of string buffers fails to account correctly for the >> trailing null byte: >> >> 1. In src/appl/strsignif.c, 'f0' and 'form' at l. 108-9 each need at >> least 1 extra byte. >> >> 2. In src/main/util.c, 'out' at l. 1081 needs at least one extra byte. >> >> (Remember that the return value of strlen does not include the null >> byte.) > > But it is subtler than that. R_alloc contains the statement > > s = allocVector(RAWSXP, size + 1); > > and so does over-allocate by at least one (there is a rounding up to a > multiple of 8). This is a historical anomaly (it used to allocate a > CHARSXP that allowed for the null byte), but one which trying to > eliminate caused too many crashes in package code. > > I'd like to see the empirical evidence you have, as I have been unable > to trigger an overrun here.
I should perhaps have explained that I discovered these faults working on a modified code base, in which in particular the valgrind instrumentation will pick up an overrun of even a single byte over the requested block size. I have no reason to suppose that the faults will lead to a failure of R as currently engineered; indeed for the reasons you cite I guess they won't. However, buffer overruns - when they do manifest themselves - can give rise to such baffling and hard-to-reproduce failures that they are like submerged rocks: well worth marking on the chart even if they're not close to current shipping lanes. Andrew Runnalls -- Dr Andrew Runnalls, Computing Laboratory, University of Kent, CANTERBURY CT2 7NF, UK Tel: (0)1227 823821 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
