Re: [Rd] Latent flaw in SEXPREC definition

From: Radford Neal <>
Date: Sat, 13 Aug 2011 21:50:09 -0400

> 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. mailing list Received on Sun 14 Aug 2011 - 01:52:25 GMT

This quarter's messages: by month, or sorted: [ by date ] [ by thread ] [ by subject ] [ by author ]

All messages

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Mon 15 Aug 2011 - 17:10:19 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.

list of date sections of archive