On 8/15/19 1:00 AM, Jan Bobek wrote:
> On 8/13/19 2:07 AM, Richard Henderson wrote:
>> On 8/10/19 5:12 AM, Jan Bobek wrote:
>>> +#define INSNOP_INIT(opT, init_stmt) \
>>> + static int insnop_init(opT)(CPUX86State *env, DisasContext *s, \
>>> + int modrm, insnop_t(opT) *op) \
>>> + { \
>>> + init_stmt; \
>>> + }
>> ...
>>> +#define INSNOP_INIT_FAIL return 1
>>> +#define INSNOP_INIT_OK(x) return ((*(op) = (x)), 0)
>>
>> Return bool and true on success.
>
> So, the reason why I did this "inverted" logic (0 = success, 1 =
> failure) is because I was anticipating I might need to differentiate
> between two or more different failures, in which case returning
> different non-zero values for different error cases makes perfect
> sense. I have not made use of it yet, but I'd rather hold on to this
> idiom at least for now, until I am 100 % sure it really is
> unnecessary.
In that case "int" still isn't the best return type -- an enumeration would be.
r~
