From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Tromey To: Keith Seitz Cc: Fernando Nasser , jingham@apple.com, Insight Maling List Subject: Re: Error message revelation Date: Tue, 24 Apr 2001 09:38:00 -0000 Message-id: <87vgnukzwt.fsf@creche.redhat.com> References: X-SW-Source: 2001-q2/msg00150.html >>>>> "Keith" == Keith Seitz writes: Keith> The problem is that we have TWO ways of returning information Keith> to the tcl code: the interpreter's result and result_ptr. I Keith> really think that both of these methods are needed in our Keith> case. The confusion comes (as you've noted) that there doesn't Keith> appear to be any consistent style by the rest of the code, so Keith> no one (including me) really knows what is supposed to be "the Keith> right way". (Something more for my styleguide/internals doc). Keith> I like the explicit method: if YOU (a command writer in gdbtk) Keith> say GDBTK_IN_TCL_RESULT, then the result from tcl is used, Keith> otherwise, it's the one you've built in result_ptr->obj_ptr. I have a question: is it more common that you'd want to use the Tcl result, or is it more common that you'd want to use the gdb result? That is, maybe it makes sense to invert the flag to GDBTK_IN_GDB_RESULT. You would know this better than me. In fact, I think really you should do whatever you think is best, since you'll be working on this code much, much more than I will. I think as long as the convention is documented and clearly used in all the gdbtk code, then it will be fine in the long run. That's particularly true if you use a helper macro and have some automatic way to test for new bugs being added (this is a technique we use in Automake, and it really does help -- we have a "maintainer-check" target which checks for the checkable parts of our coding standard. We just run this occasionally, eg before releases, and fix whatever it points out). Checking in a jumbo patch to fix all the gdbtk*.c problems would be really cool. Unfortunately it is a daunting amount of code. Finding a day or two to do cleanup is hard :-( Tom