`SDL_ClipboardDataCallback` can get called with mime type it was not set up with
I would expect my callback function to only be called for the mime types it supports -- i.e. ones I've specified in SDL_SetClipboardData. As it turns out, it can get called with other unrelated mime types.
This is fine by itself, the callback could just check userdata and determine that the mime type is not one it can handle. But the problem is that the callback can't return a sane value in that case.
From the SDL_ClipboardDataCallback documentation:
Returning NULL or setting length to 0 will cause no data to be sent to the "receiver". It is up to the receiver to handle this. Essentially returning no data is more or less undefined behavior and may cause breakage in receiving applications.
The only logical return value for an invalid mime type is NULL, but that is explicitly mentioned as undefined behaviour.
What should a SDL_ClipboardDataCallback do when it is asked to provide a mime type it wasn't registered with?
Repro steps
Set up a callback with SDL_SetClipboardData and then request a different mime type with SDL_GetClipboardData -- notice that the callback is unexpectedly called with that different mime type.
I tested this and checked into the code in one of my projects (gnome/wayland). I do indeed validate the requested mime-type and return NULL and set size to 0 when it's not a mime-type I "support". And calls for unregistered mime-types are received.
In regards to receiving requests for unregistered mime-types it's either the documentation that needs clarification that this can happen or put SDL in charge of discarding requests for unregistered mime-types before calling the user supplied SDL_ClipboardDataCallback?
The part about UB is also misleading. If a program the developer doesn't control doesn't gracefully handle NULL and size 0 being returned then there's not really anything SDL can do about it. This should not be documented as UB. I think we should change the documentation here. In case of wayland I think setting the size to 0 is the expected way to gracefully decline the request for data. I can't answer for other drivers.
What's your opinion on this @slouken ?
This is fixed for the next SDL release, thanks!