Currently, if one abruptly disconnects their Wayland connection socket (for example, by killing the compositor but not the demo program), I observe example programs getting stuck in the following lines as part of an infinite loop.

while (wl_display_prepare_read(display) != 0)
	wl_display_dispatch_pending(display);

After the socket is disconnected, libwayland will start returning -1 to all subsequent calls of functions that can return an error (like wl_display_dispatch_pending(), but not wl_display_prepare_read()), and silently do nothing when functions are called. As a result, it should be safe to delay checking for error and breaking out of the main loop until the final wl_display_dispatch_pending() call. (Eagerly checking for errors is possible but would make the code rather more complicated, as wl_display_flush() can have transient/EAGAIN failures.)

(The current code was added in commit b69f87d, which likely used the function call pattern recommended by the Wayland documentation (see wl_display_prepare_read_queue()); however, the example given there does not properly check for errors.)