[RFC] setting proper result codes

[RFC] setting proper result codes

[Martin M. Hunt]

Due to some changes made some time ago, most C functions are incorrectly setting error messages.  For example:

  Tcl_SetStringObj (result_ptr->obj_ptr, "type must be \"temp\" or \"normal\"", -1);

- or - 

  {
      char *err_buf;
      xasprintf (&err_buf, "Breakpoint #%d does not exist.", bpnum);
      Tcl_SetStringObj (result_ptr->obj_ptr, err_buf, -1);
      free(err_buf);
      return TCL_ERROR;
    }

The above examples do not actually cause an error message to be displayed.  
Using Tcl_SetObjResult() fixes this, but is a bit awkward.  For example, the first
example needs to be:

Tcl_SetObjResult (interp, Tcl_NewStringObj ("type must be \"temp\" or \"normal\"", -1));

The second example is even worse.  So I am proposing using the following for all error messages
in our C tcl functions:

void
set_result (Tcl_Interp *interp, const char *fmt,...)
{
  va_list args;
  char *buf;

  va_start (args, fmt);
  xvasprintf (&buf, fmt, args);
  va_end (args);
  Tcl_SetObjResult (interp, Tcl_NewStringObj (buf, -1));
  free(buf);
}

so in each function, you just do something like:
  set_result (interp, "the line number %d is invalid.", line_number);

This seems obvious. Am I understanding the problem fully?  Any objections or suggestions?

-- 
Martin Hunt
GDB Engineer
Red Hat, Inc.

Re: [RFC] setting proper result codes

[Keith Seitz]

On Thu, 25 Oct 2001, Martin M. Hunt wrote:

> void
> set_result (Tcl_Interp *interp, const char *fmt,...)
> {
>   va_list args;
>   char *buf;
>
>   va_start (args, fmt);
>   xvasprintf (&buf, fmt, args);
>   va_end (args);
>   Tcl_SetObjResult (interp, Tcl_NewStringObj (buf, -1));
>   free(buf);
> }

Yes, I think this is pretty obviously needed, too. Developers simply need
to remember that tcl commands in the interpreter are tcl commands: if they
return TCL_ERROR, they should leave an error message in the interpreter,
not in result_ptr. (Thanks to Tom Tromey for clarifying this some time
ago.)

Other than using "free" (should be "xfree"), I don't see a problem with
the code, and I think it would be a good addition.

Now let's talk about the name... :-)

I have been sporadically attempting to define interfaces into our C code
that others can tap. The most immediate group of developers that come to
mind: plugin writers. Ok, there aren't any, but there could be one day
before this project dies.

Unfortunately, I've only started down this road, and haven't made a whole
lot of headroom... But, gdbtk-cmds.h does exist and contain some useful
functions, although they all suffer from severe namespace problems.

What I think I would like to do is have all the really external functions
(like our call wrapper) begin with "insight_". Right now, nothing does
that, but your result-setting thingy could be the first! (Anyone have a
problem with this?)

Keith