Uncaught exception handling incoming message for wl_shm@5: "Invalid format enum value 942948952"

[MisterDA]

Running the example (commit 1513420d35f3edb6ad2d9e1db0227e3cd9b9b76c) gives:

$ dune exec -- example/test.exe -h
test.exe: [INFO] Connecting to "/run/user/1000/wayland-1"
test.exe: [ERROR] Uncaught exception handling incoming message for wl_shm@5:
                  Exception: Failure("Invalid format enum value 942948952")
                  Raised at Stdlib.failwith in file "stdlib.ml", line 29, characters 17-33
                  Called from Wayland__Wayland_client.Wl_shm._handlers_unsafe#dispatch in file "lib/wayland_client.ml", line 543, characters 21-71
                  Called from Wayland__Connection.process_recv_buffer in file "lib/connection.ml", line 21, characters 12-44
test.exe: [ERROR] Uncaught exception handling incoming message for wl_shm@5:
                  Exception: Failure("Invalid format enum value 942948929")
                  Raised at Stdlib.failwith in file "stdlib.ml", line 29, characters 17-33
                  Called from Wayland__Wayland_client.Wl_shm._handlers_unsafe#dispatch in file "lib/wayland_client.ml", line 543, characters 21-71
                  Called from Wayland__Connection.process_recv_buffer in file "lib/connection.ml", line 21, characters 12-44

The test example runs fine as expected though, but this exception is still intriguing. I'm using Arch Linux, sway-git and wlroots-git if that changes anything.

[talex5]

They got added in https://gitlab.freedesktop.org/wayland/wayland/-/commit/1638dad6137d7dd26a4a8c5d931bbb5c52dda46c

Perhaps we need to add an Unknown variant to every enum to represent new additions. Or maybe enums should be defined as type t = private int32, and applications can try converting to the variant form as needed?

[talex5]

Fixed in https://github.com/talex5/ocaml-wayland/commit/b349d6df6fa1837e0f2565378570ce8b68ec3431.