summaryrefslogtreecommitdiff
path: root/AUTHORS
diff options
context:
space:
mode:
authorPhilip Withnall <philip.withnall@collabora.co.uk>2014-06-23 01:00:40 +0100
committerPhilip Withnall <philip.withnall@collabora.co.uk>2014-06-27 17:36:52 +0100
commitd395a38afc6410bc9d60f501745300305e137b37 (patch)
tree190c487d09e0771cdfbd43d5ba5ee58f9f220258 /AUTHORS
parent10ba1c82bd6f58ccab99eda85416ec5600ac015d (diff)
gsignal: Correctly handle incorrect parameter counts in signal callbacks
This is a minefield. g_signal_connect_swapped() is intended to be used in situations where the number of formal parameters in the callback function differs from the number of actual parameters emitted by the signal. This allows the common idiom of (e.g.) calling gtk_widget_hide() on a signal callback from another object, with the widget being passed in the user_data. It turns out that these situations are entirely implementation defined. The C specification disavows all knowledge of how parameter passing should work when the callback function prototype isn’t known, leaving this to the calling convention to define. All calling conventions that we care about handle this sensibly, explicitly covering the case of the number of actual parameters exceeding the number of formal parameters, just like they handle varargs. However, there are a few calling conventions which won’t handle this properly, and will cause explosions should you try. For example, I believe that passing a WinAPI function (calling convention: stdcall) as a signal callback will cause problems. I haven’t verified this experimentally though. The gsignal-checker now allows for the number of formal and actual parameters to differ, but only if the calling convention for the callback function is safe. That should cover things.
Diffstat (limited to 'AUTHORS')
0 files changed, 0 insertions, 0 deletions