From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22690 invoked by alias); 11 Sep 2002 19:27:09 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 22672 invoked from network); 11 Sep 2002 19:27:09 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 11 Sep 2002 19:27:09 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id g8BJR7u29266; Wed, 11 Sep 2002 12:27:07 -0700 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Daniel Jacobowitz Cc: gdb Subject: Re: struct environment References: <20020906150620.GA19200@nevyn.them.org> <20020906175726.GA7265@nevyn.them.org> <20020911183628.GA30630@nevyn.them.org> Content-Type: text/plain; charset=US-ASCII From: David Carlton Date: Wed, 11 Sep 2002 12:27:00 -0000 In-Reply-To: <20020911183628.GA30630@nevyn.them.org> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 X-SW-Source: 2002-09/txt/msg00104.txt.bz2 On Wed, 11 Sep 2002 14:36:28 -0400, Daniel Jacobowitz said: > On Wed, Sep 11, 2002 at 11:33:08AM -0700, David Carlton wrote: >> But I think I was making too much of the memory-management >> difficulties: I'll do iterators correctly (so you can have as many >> of them active as you want), and just write an ALL_ENV_SYMBOLS >> macro that allocates them on the stack using alloca(). > Or you could just require an iterator to be declared in the function > which uses ALL_BLOCK_SYMBOLS.... why bring alloca into it? The > pointer you allocate into would need to be a local variable so the > iterator might as well just be a local variable. Sure, it makes > them a tiny bit less opaque. But make them opaque -in practice-. I know, I'm too in love with opacity right now. Chalk it up to the bad influence of C++, or something. (What, I can't just store my pointer in a std::auto_ptr and have its contents deleted automatically when it goes out of scope?) Having said that, there's a bit more reason for these types to be opaque than normal. There will be multiple implementations of environments: currently fixed-size hash, fixed-size linear, and expandable linear (for use by jv-lang.c and mdebugread.c, sigh), plus two temporary implementions using struct block that will only exist until all the block code is switched over to using environments. And once I tackle global symbols, there will be at least one new permanent environment implementation and one new temporary environment implementation to handle that, too. Also, there is literally no information that is common to all the different implementations, so it simply doesn't make sense to have publically-accessible macros to get at parts of the environment, for example. So it would be nice if, say, adding new implementations was all localized to environment.c plus adding one creation function prototype to symtab.h, rather than polluting symtab.h with lots of data that only environment.c will use. But, on the other hand, alloca() should still be avoided if possible. And it's not like the solution using alloca() is all that clean: in an opaque implementation, I can't alloca(sizeof struct env_iterator), so I would have to provide a function call env_sizeof_iterator() to return that information. And I suspect that, once we move on to the global environment, we'll want to add a 'parent environment' member to environments that will be there for all implementations, so it might make sense to make environments slightly less opaque. It's even possible that, for performance reasons, some of the functions will have to be turned into macros eventually. I'll think about it some more. It might well be the case that all iterators would just need a struct environment *, a struct symbol **, and an integer: so they all have the same data, but use it in different ways depending on how the struct environment is implemented. If that's the case, it would be perverse to use alloca(): I can certainly break opaqueness to that extent. David Carlton carlton@math.stanford.edu