From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29226 invoked by alias); 3 Sep 2010 16:14:52 -0000 Received: (qmail 29211 invoked by uid 22791); 3 Sep 2010 16:14:50 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 03 Sep 2010 16:14:44 +0000 Received: (qmail 11961 invoked from network); 3 Sep 2010 16:14:42 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 3 Sep 2010 16:14:42 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [patch] Fix nesting of ui_out_redirect Date: Fri, 03 Sep 2010 18:17:00 -0000 User-Agent: KMail/1.13.2 (Linux/2.6.33-29-realtime; KDE/4.4.2; x86_64; ; ) Cc: Jan Kratochvil , pebolle@tiscali.nl References: <20100903112139.GA20855@host1.dyn.jankratochvil.net> <201009031404.23364.pedro@codesourcery.com> <20100903152332.GA30657@host1.dyn.jankratochvil.net> In-Reply-To: <20100903152332.GA30657@host1.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009031714.41019.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-09/txt/msg00132.txt.bz2 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