Hi Richard,
On Fri, Jan 15, 2016 at 2:59 PM, Richard Plangger wrote:
> I have fixed this issue at the call site. The caller sign/zero extends
> narrower integer types. The reason I did not change it to that in the
> first place is: I thought that it is not easy to determine this
> information at
Hi David,
On Fri, Jan 15, 2016 at 2:28 PM, David Edelsohn wrote:
>> In more details: my point of view is that libffi is *documented* to
>> return the value
>> 0x097a, but instead it returns 0xdeadbeefdead097a.
>
> libffi is *documented* to return the non sign-extended value.
Ok. I t
Hi,
> libffi is *documented* to return the non sign-extended value.
I have fixed this issue at the call site. The caller sign/zero extends
narrower integer types. The reason I did not change it to that in the
first place is: I thought that it is not easy to determine this
information at the calls
On Fri, Jan 15, 2016 at 3:33 AM, Armin Rigo wrote:
> Hi Richard,
>
> On Thu, Jan 14, 2016 at 6:32 PM, Richard Plangger wrote:
>> -- parameter (1213,1213) both 64-bit
>> > as 64bit integer> (2)
>
> Do you mean in both cases 16-bit integer instead of 64-bit integer?
>
>> returns every f
Hi Richard,
On Thu, Jan 14, 2016 at 6:32 PM, Richard Plangger wrote:
> -- parameter (1213,1213) both 64-bit
> as 64bit integer> (2)
Do you mean in both cases 16-bit integer instead of 64-bit integer?
> returns every frame back to and saves 0xdeadbeefdead097a
> My understanding is
