From radford at cs.toronto.edu  Sun Aug 14 03:50:09 2011
From: radford at cs.toronto.edu (Radford Neal)
Date: Sat, 13 Aug 2011 21:50:09 -0400
Subject: [Rd] Latent flaw in SEXPREC definition
In-Reply-To: <7DE8973C-B303-4201-9964-F5117FD283E8@gmail.com>
References: <20110813205643.GA4049@cs.toronto.edu>
	<7DE8973C-B303-4201-9964-F5117FD283E8@gmail.com>
Message-ID: <20110814015009.GA746@cs.toronto.edu>

> 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.



[Rd] Latent flaw in SEXPREC definition
Radford Neal