Re: [PATCH] guile/: Add enum casts

[Pedro Alves <palves@redhat.com>]

On 10/28/2015 07:36 PM, Pedro Alves wrote:
> On 10/28/2015 07:29 PM, Simon Marchi wrote:
> 
>> The status comes from gdbscm_disasm_read_memory returning TARGET_XFER_E_IO:
>>
>>   return status != NULL ? TARGET_XFER_E_IO : 0;
>>
>> Does it make sense that this function returns TARGET_XFER_E_IO, and
>> not just -1 (or any other non-zero value) on error?  It's an
>> all-or-nothing memory read function, unlike those of the xfer_partial
>> interface.
>>
>> I would have done a change similar to what you have done in
>> target_read_memory&co: make gdbscm_disasm_read_memory return -1 on
>> error, and change
>>   memory_error (status, memaddr);
>> to
>>   memory_error (TARGET_XFER_E_IO, memaddr);
>>
>> Would it make sense?
> 
> I had the same thoughts when I did the target_read_memory&co patch,
> and went through all the memory_error callers.  In the end I left
> it be because of the IWBN comment:
> 
>   /* TODO: IWBN to distinguish problems reading target memory versus problems
>      with the port (e.g., EOF).
>      We return TARGET_XFER_E_IO here as that's what memory_error looks for.  */
>   return status != NULL ? TARGET_XFER_E_IO : 0;
> 
> Either way is fine with me.  Doug, what would you prefer?
> 
> Cast?
> Hardcode TARGET_XFER_E_IO in the memory_error call?
> Other?

Hmm, reading the comment back, I actually agree with Simon.
The comment refers to distinguishing memory errors from something
else not memory errors.  In that "something else" case, sounds like
we wouldn't end up calling memory_error at all.  So sounds like Simon's
suggestion would be the clearer way to go.  WDYT?

Thanks,
Pedro Alves