Re: valid_pointer_p

[storm@cua.dk (Kim F. Storm)]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andreas Schwab <schwab@suse.de>
>> Cc: storm@cua.dk (Kim F. Storm), emacs-devel@gnu.org
>> Date: Sat, 12 Aug 2006 14:36:22 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > ??? Don't we have macros, like INTEGERP, SUBRP, etc. to do that
>> > without dereferencing?  The length of the primitive Lisp types is
>> > known, right?
>> 
>> Try to find out the size of a vector object.
>> 
>>     /* Vector of Lisp objects, or something resembling it.
>>        XVECTOR (object) points to a struct Lisp_Vector, which contains
>>        the size and contents.  The size field also contains the type
>>        information, if it's not a real vector object.  */
>>     Lisp_Vectorlike,
>
> I think something like this should work for such cases:
>
>       struct Lisp_Vector *p = XVECTOR (obj);
>
>       if (valid_pointer_p (p, offsetof (struct Lisp_Vector, size)
>       	 		      + sizeof (EMACS_INT))
>       	  && valid_pointer_p (p, p->size))
> 	return 1;  /* valid */
>
> (Modulo the complications of storing other information in the leading
> bits of the `size' field of struct Lisp_Vector.)  This is what I meant
> when I wrote:
>
>     Even if you are right, dereferencing a pointer accesses a region in
>     memory whose length is known in advance, so at most we will need to
>     call valid_pointer_p twice.
>
> Am I missing something?

No.  My simple approach was simply to assume that if you can access the
size field of a vector, you can access the rest as well.  I don't mind
making a more correct implementation, although I didn't see the need --
after all, this is for a corner case of debugging emacs.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk