On Thu, 23 Feb 2017 13:47:41 +0100
Carlos Garnacho <carl...@gnome.org> wrote:

> New IDs are internally dealt with as objects, however this test
> expected to deal with 'n' as the uint32_t type that's just seen
> through the wire. We should give it an object instead, and
> expect an object from it.
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=99899
> 
> Signed-off-by: Carlos Garnacho <carl...@gnome.org>
> ---
>  tests/connection-test.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/tests/connection-test.c b/tests/connection-test.c
> index 1c688f1..8be6c38 100644
> --- a/tests/connection-test.c
> +++ b/tests/connection-test.c
> @@ -142,7 +142,7 @@ va_list_wrapper(const char *signature, union wl_argument 
> *args, int count, ...)
>  TEST(argument_from_va_list)
>  {
>       union wl_argument args[WL_CLOSURE_MAX_ARGS];
> -     struct wl_object fake_object;
> +     struct wl_object fake_object, fake_new_object;
>       struct wl_array fake_array;
>  
>       va_list_wrapper("i", args, 1, 100);
> @@ -154,13 +154,13 @@ TEST(argument_from_va_list)
>  
>       va_list_wrapper("?iuf?sonah", args, 8,
>                       102, 103, wl_fixed_from_int(104), "value",
> -                     &fake_object, 105, &fake_array, 106);
> +                     &fake_object, &fake_new_object, &fake_array, 106);
>       assert(args[0].i == 102);
>       assert(args[1].u == 103);
>       assert(args[2].f == wl_fixed_from_int(104));
>       assert(strcmp(args[3].s, "value") == 0);
>       assert(args[4].o == &fake_object);
> -     assert(args[5].n == 105);
> +     assert(args[5].o == &fake_new_object);
>       assert(args[6].a == &fake_array);
>       assert(args[7].h == 106);
>  }

Makes perfect sense to me by matching the function to be tested and the
use in wl_closure_marshal() which reads .o, not .n field.

Good thing the bug is in the test, not in the library.

Reviewed-by: Pekka Paalanen <pekka.paala...@collabora.co.uk>

Kalev, please test. Obvously the broken test passed for every other
arch.

I suppose that maybe 64-bit alignment of pointers saved us on x86_64?
Or why else would the vararg parsing have succeeded for the elements
after the new_id arg?


Thanks,
pq

Attachment: pgp_PHLXlQrjf.pgp
Description: OpenPGP digital signature

_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Reply via email to