Re: Building solib-target.c when CORE_ADDR != ULONGEST.

[Daniel Jacobowitz <drow@false.org>]

On Sun, Jul 08, 2007 at 03:32:02PM +0100, Pedro Alves wrote:
> About the VEC in question.  I noticed that the xml parsing
> xmalloc's the memory for the ULONGEST, but it is safe to
> pass a pointer in a local var, right?

Yes, that's right.  The patch is OK.

> I got confused because in vec.h:
> 
>      "Because of the different behavior of structure objects, scalar
>       objects and of pointers, there are three flavors, one for each of
>       these variants.  Both the structure object and pointer variants
>       pass pointers to objects around -- in the former case the pointers
>       are stored into the vector and in the latter case the pointers are
>       dereferenced and the objects copied into the vector.  The scalar
>       object variant is suitable for int-like objects, and the vector
>       elements are returned by value.  "
> 
> Something in there confuses me.  The former/latter type of
> descriptions adds an indirection that I always find
> distracting.

Far as I can tell, Nathan got his formers and his latters crossed, and
that's why it doesn't make sense.

It would have made more sense for me to use DEF_VEC_I for these than
the DEF_VEC_O I actually used, but to be honest I didn't realize it
was there.  The use of DEF_VEC_O makes this rather more confusing
than necessary.

> The 'by value' statement isn't clear to me either:
> "object variant is suitable for int-like objects, and the vector
>       elements are returned by value.  "
> 
> T *VEC_T_index(VEC(T) *v, unsigned ix); // Object
> 
> ?  What does 'by value' mean then?

The previous word is "scalar".  Scalar object -> integer, not
structure object.  So the last bit of your correction is wrong.


> 2007-07-08  Pedro Alves  <pedro_alves@portugalmail.pt>
> 
> 	* solib-target.c (library_list_start_segment): Cast address to CORE_ADDR.

OK.

-- 
Daniel Jacobowitz
CodeSourcery