diff options
author | Philip Withnall <philip.withnall@collabora.co.uk> | 2014-06-23 01:00:40 +0100 |
---|---|---|
committer | Philip Withnall <philip.withnall@collabora.co.uk> | 2014-06-27 17:36:52 +0100 |
commit | d395a38afc6410bc9d60f501745300305e137b37 (patch) | |
tree | 190c487d09e0771cdfbd43d5ba5ee58f9f220258 /AUTHORS | |
parent | 10ba1c82bd6f58ccab99eda85416ec5600ac015d (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