This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Fix nesting of ui_out_redirect

On Friday 03 September 2010 16:23:32, Jan Kratochvil wrote:
> > It looks easy to tweak vec.h to get rid of the typedef, and so be able to
> > forward declare VECs.  E.g.,:
> OK but that is not a part of this patch and the typedef is the GDB norm now.

Excuse me for coming back to this, but I'd like to leave a note for the
archives, as I'm not sure there wasn't some confusion what typedef I
was talking about (and I have a feeling I'll point at this thread
some time in the future):

> Index: src/gdb/vec.h
> ===================================================================
> --- src.orig/gdb/vec.h  2010-06-16 12:36:45.000000000 +0100
> +++ src/gdb/vec.h       2010-09-03 13:45:33.000000000 +0100
> @@ -392,16 +392,21 @@ extern void *vec_o_reserve (void *, int,
>  #define vec_assert(expr, op) \
>    ((void)((expr) ? 0 : (gdb_assert_fail (op, file_, line_, ASSERT_FUNCTION), 0)))
> -#define VEC(T) VEC_##T
> +#define VEC_TAG(T) VEC_##T
>  #define VEC_OP(T,OP) VEC_##T##_##OP
> +#define DEC_VEC(T)                                                       \
> +  struct VEC_TAG(T)
> +
>  #define VEC_T(T)                                                         \
> -typedef struct VEC(T)                                                    \
> +struct VEC_TAG(T)                                                        \
>  {                                                                        \
>    unsigned num;                                                                  \
>    unsigned alloc;                                                        \
>    T vec[1];                                                              \
> -} VEC(T)
> +}

It's this ^^^typedef I was talking about.  It's an internal detail
to vec.h.  That typedef what prevents forward declaring "VEC(T);" easily.
Getting rid of it allows writing the DEC_VEC (DEClare VECtor) macro as
above.  I was not talking about the ui_filep (the T) typedef.  No client
code would be affected by that change.  Only code that wanted to
forward the declare the VEC would now be able to do so.

> +
> +#define VEC(T) struct VEC_TAG(T)
>  /* Vector of integer-like object.  */
>  #define DEF_VEC_I(T)                                                     \
> (END) 

Pedro also wrote:

> but I'm really not sure it's worth it to have.  Each module that
> wants to use the VEC still needs to "DEF_VEC_P (ui_filep)"
> (or similar), given that that defines the bunch of static inline
> functions that actually manipulate the VEC.  We'd probably
> want something like this in the headers:

> DEC_VEC (ui_filep);
> #define DEF_VEC_ui_filep \
> DEF_VEC_P (ui_filep)

> and then in the .c files that actually use the VEC, write

> DEF_VEC_ui_filep;

> somewhere at the top.  (replace ui_filep with your favorite
> type name, and _P with _I or _O appropriately, of course.)

Pedro Alves

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]