> But the whole point of separating VECTOR_SEXPREC from the other > SEXPRECs is that they are _shorter_. A vecsxp is only going to be > larger than (say) an envsxp if 2 R_len_t's are more than 3 pointers, > which is quite unlikely since R_len_t variables holds things that > one might add to pointers.
Unlikely, yes, but it's not inconceivable that someone might have a configuration where R_len_t is 64 bits (say, for some sort of compatibility reason) while pointers are 32 bits (say, for speed). > NOT having vecsxp in the SEXPREC union prevents programmers from > mistakingly using SEXP* where VECSXP* should have been used. Since > the distinction wasn't always there, I suspect that flagging usage > of x->u.vecsxp.length by the compiler was rather important at some > point in time. If that's an issue, one can just call the field something other than vecsxp. Of course, an alternative solution is to not use allocSExpNonCons to allocate zero-length vectors. ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
