From: Satish Balay (balay_at_mcs.anl.gov)
Date: Wed Apr 03 2002 - 20:45:32 BST
The reason for the separation is - so that the main routine doesn't
access the members of this structure directly (data encapsulation?).
But when debugging - it would be nice if the dat in this stuff can be
checked.
Satish
On Wed, 3 Apr 2002, Rod Armstrong wrote:
> I understand the problem now. Without defining the type in file x.c,
> ups cannot expand it. This is because type information is scoped to
> compilation units. Why not include the type definitions in files
> where you want to examine the structure? The ups type scoping
> is just the same as the compiler. For instance, if x.c were written as:
>
> typedef struct _p_Vec* Vec;
> main(void)
> {
> Vec v;
> VecCreate(&v);
> v.type = 0;
> }
>
> gcc will fail to compile it:
>
> x.c: In function `main':
> x.c:6: request for member `type' in something not a structure or union
>
> A workaround is to use an expresion to cast the address in a file where the
> type is defined:
>
>
> Source files
> y.c
> (struct _p_Vec *)0x215c0 0x215c0
> int <a[0]> 0
> char <type{0}> *NULL
> Breakpoints
> Functions
> main x.c:6
> undefined struct _p_Vec *<v> 0x215c0
>
> (you can use an editing macro to help:
>
> setenv UPS_F1_STR "^y_at_b^ @b^w^b^d)^a(\n"
>
> then select "struct _p_Vec *<v> 0x215c0" in main(), add expr to y.c and use
> the menu to transform the text.)
>
> Rod
>
>
This archive was generated by hypermail 2.1.4 : Thu May 23 2002 - 15:54:08 BST