Fix #1031 - incorrect call offsets calculated in DOS EXEs

That was removed in my second commit FYI.
On Jun 15, 2014 7:24 PM, "radare" <notifications@github.com> wrote:

> In libr/anal/p/anal_x86_udis.c:
>
> > @@ -385,9 +385,13 @@ case 48:
> >  			op->type = R_ANAL_OP_TYPE_UCALL;
> >  			op->jump = 0; // EAX, EBX, ... use anal->reg
> >  			break;
> > +		case UD_OP_PTR:
> > +			op->jump = (int)getval (&u.operand[0]);
> > +			if ((&u.operand[0])->size == 32)
>
> yep. that’s just an overcomplicated syntax
> … <#146a1d838bbd6d92_>
> On 14 Jun 2014, at 21:05, Jann Horn <notifications@github.com> wrote: In
> libr/anal/p/anal_x86_udis.c: > @@ -385,9 +385,13 @@ case 48: > op->type =
> R_ANAL_OP_TYPE_UCALL; > op->jump = 0; // EAX, EBX, ... use anal->reg >
> break; > + case UD_OP_PTR: > + op->jump = (int)getval (&u.operand[0]); > +
> if ((&u.operand[0])->size == 32) Just a remark about code style: Am I
> missing something, or could you also write this as if (u.operand[0].size ==
> 32)? — Reply to this email directly or view it on GitHub.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/radare/radare2/pull/1032/files#r13789041>.
>