Re: [patch] Fix `return' of long/long-long results with no debuginfo

Tom Tromey
2009-03-11T18:37:01Z

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

>> 2009-03-09 Jan Kratochvil <jan.kratochvil@redhat.com>
>>
>> * stack.c (return_command <retval_exp>): New variables retval_expr
>> and old_chain. Inline parse_and_eval to initialize retval_expr. Check
>> RETVAL_EXPR for UNOP_CAST and set RETURN_TYPE to the RETURN_VALUE type
>> if RETURN_TYPE is NULL.

Joel> This looks good to me, but I don't understand the error message when
Joel> the user forgot to cast the result. I wonder if we shouldn't just
Joel> preserve the old behavior which is to implicitly cast to "int"?

We've come full circle :-)

The original patch was motivated by a case where casting to int gave a
bad result. Then Mark had a counter-proposal, which was to use the
expression's type, rather than assuming 'int'. Finally, I suggested
simply requiring a cast, resulting in this patch.

So, the real question for you is how you think it ought to work.
I think we have implementations of all of the approaches now.

Tom