public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org
Cc: Jan Kratochvil <jan.kratochvil@redhat.com>, pebolle@tiscali.nl
Subject: Re: [patch] Fix nesting of ui_out_redirect
Date: Fri, 03 Sep 2010 18:17:00 -0000	[thread overview]
Message-ID: <201009031714.41019.pedro@codesourcery.com> (raw)
In-Reply-To: <20100903152332.GA30657@host1.dyn.jankratochvil.net>

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

      parent reply	other threads:[~2010-09-03 16:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-03 15:33 Jan Kratochvil
2010-09-03 15:36 ` Pedro Alves
2010-09-03 15:40   ` Jan Kratochvil
2010-09-03 15:40     ` Pedro Alves
2010-09-03 18:01       ` Jan Kratochvil
2010-09-03 18:17     ` Pedro Alves [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201009031714.41019.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    --cc=pebolle@tiscali.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).