On 20 Feb 2004, Peter Dalgaard wrote: > Prof Brian Ripley <[EMAIL PROTECTED]> writes: > > > All of these stem from the use of constructions like > > > > len = asInteger(CADR(args)); > > > > and a failure to check the return value for NA. > > > > We'll add suitable checks, so don't bother with a bug report. > > We should probably take notice that these integer calculations > effectively limit the size of a vector to 2G-elements (2^31-1 == > 2147483647), i.e. 16GB for numeric() and 8GB for integer(). That's > hardly going to bite many people just now, but within a few years it > might.
It's more fundamental than those calculations: allocVector is defined as SEXP allocVector(SEXPTYPE type, int length) and is part of the API. Quite a lot of the internal length calculations are in ints, too. We could change the API now to R_size_t (unsigned long) as I don't think it would break anything except already compiled code on 64-bit platforms. (But code would need to be altered to make good use of the change). There is another problem, silent overflow of calculations like nc * ns, of which I found a couple of instances and there may be more. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595 ______________________________________________ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
