Bill Allombert on Thu, 18 Sep 2008 18:37:14 +0200

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: Length of PARI types

On Thu, Sep 18, 2008 at 10:38:49AM +0200, Jeroen Demeyer wrote:
> Hello,
> I have a question about the following paragraph from the libpari 
> documentation about cgetg():
> Note that the length argument $l$ is predetermined for a number of 
> types: 3 for types \typ{INTMOD}, \typ{FRAC}, \typ{COMPLEX}, 
> \typ{POLMOD}, \typ{RFRAC}, 4 for type \typ{QUAD} and \typ{QFI}, and 5 
> for type \typ{PADIC} and \typ{QFR}. However for the sake of efficiency, 
> \kbd{cgetg} does not check this: disasters will occur if you give an 
> incorrect length for those types.
> I can imagine that "disasters" can occur if these types are allocated 
> with too few space, but what can go wrong if any of these types is 
> allocated with more codewords than required?  I think that should be okay?

Unless you fill in those extracode words with pointers to valid GEN,
functions like gerepile and gcopy will fail (by attempting to read
the extra words), so it is accurate to say that e.g.

GEN y, z = cgetg(4, t_COMPLEX);
gel(z,1) = gen_1;
gel(z,2) = gen_1;
y = gcopy(z);

will fail. In any case, extra codewords are ground for undefined behaviour.