[Rd] Latent flaw in SEXPREC definition

[Radford Neal]

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