Re: [RFA] Function return type checking

[Daniel Jacobowitz <drow@mvista.com>]

On Tue, Feb 05, 2002 at 01:36:41AM -0800, Klee Dienes wrote:
> (This is basically the same patch I sent last week, just updated
> to the latest source base.)
> 
> The following patch adds "expected return type" support to the target
> function call interface.  The "expected return type" is specified
> using cast syntax; it is ignored if actual type information for the
> function is available.  If no type information is provided for a
> function, the user is now required to provide an expected return type
> using the cast syntax, or get an error.

Having thought about this since you last posted it, I don't really like
it.  What you do by overloading the cast syntax for this operation is
very ``cute'', but exceedingly unintuitive.

> Some examples:
> 
> (gdb) print fabs (3.0)                  (no type information present)
> Unable to call function at 0x%lx: no return type information available.
> To call this function anyway, you can cast the return type explicitly
> (e.g. 'print (float) fabs (3.0)').

Except for the syntax of the example, I like this message.  This is a
good message.  We need more warnings about doing things like this.

Fabs is a bad example, though - can I suggest you look over the list of
what GCC defines as builtin functions, and not choose one?

> The reason I suggest 2) might be controversial is that the old
> behavior can be convenient in the general case.  A lot of functions
> *do* return int, and when debugging programs without symbols, it can
> be annoying to have to declare the return type, just to make the rare
> case when functions return floats/structs behave correctly.  But I'd
> argue that it's not *that* big a deal to cast a return value, and
> correctness must always take priority.

Losing the implicit int doesn't bother me especially.

Have you considered casting the function itself?  Something like:
(gdb) print ((float (*)(float)) fabs) (3.0)
$1 = 3.0
(gdb) set fabs

Which, I will note, already works except for the fact that we neglect
the argument types on function pointers.  Or
(gdb) set $fabs = (float (*)(float)) fabs
(gdb) p $fabs(4.0)
$2 = 4.0

Which works with the same caveat.

Specifying just the return type of the function is not useful in the
general case.  If we do not understand the argument types, it will
still crash.  I was trying to find an example where float vs. double
would cause a problem too, but I can't think of one at the moment. 
There's one in the testsuite though, for some targets.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer