This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] Alternate approach to keeping convenience variables
- From: Jim Blandy <jimb at red-bean dot com>
- To: Andrew STUBBS <andrew dot stubbs at st dot com>
- Cc: Eli Zaretskii <eliz at gnu dot org>, gdb-patches at sources dot redhat dot com
- Date: Tue, 24 Jan 2006 10:40:58 -0800
- Subject: Re: [RFC] Alternate approach to keeping convenience variables
- References: <4381DC75.80800@st.com> <8f2776cb0511212138g2adef40cr1632365c00e3bebc@mail.gmail.com> <43835114.5060401@st.com> <20051209205923.GA21331@nevyn.them.org> <ud5k5e2xe.fsf@gnu.org> <8f2776cb0601231429y38714c9bm830991b4b037ec70@mail.gmail.com> <43D60D20.2080004@st.com>
On 1/24/06, Andrew STUBBS <andrew.stubbs@st.com> wrote:
> Jim Blandy wrote:
> > The $trace_frame variable is set to -1 when GDB starts, which
> > indicates that there's no trace frame selected. I think it would be a
> > little more helpful for the variables to always exist: you can write
> > user-defined commands that give a reasonable error message, for
> > example. GDB doesn't have any way (?) to check whether a convenience
> > variable has been initialized yet.
>
> A newly created convenience variable has the value 'void'. (A variable
> is created the first time it is referenced, even as an rvalue.)
> Therefore, if it is 'void' it can be considered uninitialised.
Right, but there's no way to test for that in the scripting language.
Your 'init-if-undefined' command has to be a primitive, implemented in
C. My argument was that having the variables always be present is
more convenient for user-defined commands.