This came up while looking at bug #707170. The issue is NULL is passed as the return value to closures only when G_ENABLE_DEBUG is set (and the closure doesn't specify a return type). This forces implemented closures to react to two different cases for closures which don't return a value. This most likely isn't much of a problem since closure implementers would generally leave the return_value alone for closures without returns, but for binding layers we need to compute things at runtime.

The docs for GClosureMarshal note:

"return_value : ... May be NULL if the callback of closure doesn't return a value. [allow-none]"

https://developer.gnome.org/gobject/stable/gobject-Closures.html#GClosureMarshal

In short, it seems a bit odd to have different behaviours depending on whether or not G_ENABLE_DEBUG is set. I can't think of a good reason to have this difference and perhaps it was a mistake of being a bit overzealous when the G_ENABLE_DEBUG check was added 13 years ago?
https://git.gnome.org/browse/glib/tree/gobject/gsignal.c?id=2.37.6#n3030

At this point, it might also be a bit of a problem to always set this to NULL because it could break people who only rely on release builds for development and have never needed a NULL check. If we were to make this consistent, I think never setting it to NULL would be the safer bet. If making it consistent is not desired, Minimally I think the docs could be a bit more specific, e.g. "May be NULL or invalid if ..."

But even that would not be totally correct because I think the return_value will point to what the caller of g_signal_emitv passed in.