WAYLAND_DISPLAY lets you do a buffer overflow
A couple examples of fragile code, so my comment is a little constructive:
- I truly dislike the cstring_len macro, which sounds like strlen yet its semantics are completely different.
- The wayland_display_connect function returns EINVAL or an fd. Both are positive integers. It should instead return -EINVAL.
- The functions benefit from more comments, because they do a lot and are not factored to smaller, more composable units.
- wayland_handle_message should be refactored so it's a simple switch that operates on constants, and ideally delegates to other functions.
- Probably outside of the scope of a simple article, but all the buffer boilerplate should be simplified by using a buffer structure that holds pointer, cursor and capacity, to make the code much more readable.
Or maybe return -1 and set errno? I haven't seen many C programs that return negative errnos (excepting the linux kernel which uses negative errnos internally).
Is that actually possible? Opcodes by themselves are not unique, and the object IDs are right now assigned at runtime (I can’t tell if that’s actually necessary).
It's lazy and quite ignorant to criticize teaching material because it doesn't cover all possible corner cases, and because it doesn't account for a reader that just wants to copy the code without understanding it.
The topic is Wayland, not C code hardening techniques for internet facing services. Quit being an obnoxious pedant.
But this is not production code, and shouldn't be read this way.
In my opinion the writer quite clearly establishes that this code and methodology is only intended to be illustrative of the broader subject, which is: how Wayland works.
And inasmuch as it is illustrative, the very many exploits it shows are explicitly available, is a root note of its value. This author knows whats up.