After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 761975 - Unable to set default handler for unix signal
Unable to set default handler for unix signal
Status: RESOLVED FIXED
Product: vala
Classification: Core
Component: Bindings
unspecified
Other Linux
: Normal minor
: ---
Assigned To: Michael 'Mickey' Lauer
Vala maintainers
Depends on: 793444
Blocks:
 
 
Reported: 2016-02-12 22:26 UTC by Jens Georg
Modified: 2018-02-21 09:25 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jens Georg 2016-02-12 22:26:12 UTC
When compiling

int main (string[] args) {
    var action = Posix.sigaction_t ();
    action.sa_handler = Posix.SIG_DFL;
    Posix.sigaction (Posix.SIGINT, action, null);

    return 0;
}

I get C compiler errors such as:

valac foo.vala  --pkg posix
/home/jens/foo.vala.c: In function ‘_vala_main’:
/home/jens/foo.vala.c:20:2: error: unknown type name ‘sighandler_t’
  sighandler_t _tmp0_ = NULL;
  ^
/home/jens/foo.vala.c:20:24: warning: initialization makes integer from pointer without a cast [-Wint-conversion]
  sighandler_t _tmp0_ = NULL;
                        ^
/home/jens/foo.vala.c:23:9: warning: assignment makes integer from pointer without a cast [-Wint-conversion]
  _tmp0_ = SIG_DFL;
         ^
/home/jens/foo.vala.c:24:20: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
  action.sa_handler = _tmp0_;
                    ^
error: cc exited with status 256
Compilation failed: 1 error(s), 0 warning(s)
Comment 1 Jens Georg 2016-02-12 22:31:02 UTC
Looking into signal.h, sighandler_t needs __USE_GNU defined.

#ifdef __USE_GNU
typedef __sighandler_t sighandler_t;
#endif
Comment 2 Al Thomas 2016-02-13 11:40:50 UTC
From your comment it looks like you need a feature macro set when compiling.
Something like valac -X -D__USE_GNU

See https://bugzilla.gnome.org/show_bug.cgi?id=756315 for an example

Setting macros like this from the VAPI is not possible.
Comment 3 Jens Georg 2016-02-13 22:17:01 UTC
I've seen the comment regarding crypt and tried that, but it doesn't seem to work, not even from a simple C program.

I think usually you don't need siginfo_t explicitly and because you don't assign the handlers to variables.
Comment 4 Al Thomas 2018-01-19 16:48:18 UTC
(In reply to Jens Georg from comment #3)
> I've seen the comment regarding crypt and tried that, but it doesn't seem to
> work, not even from a simple C program.

FWIW the following works with your example in comment #0:

valac --pkg posix -X -D_GNU_SOURCE signal_handler_example.vala

This is from man 2 signal (http://man7.org/linux/man-pages/man2/signal.2.html):
"The use of sighandler_t is a GNU extension, exposed if _GNU_SOURCE is defined"

Although I'm not finding anything in the GNU documentation that states _GNU_SOURCE is the feature macro. The closest I can find is from http://www.gnu.org/software/libc/manual/html_node/Basic-Signal-Handling.html :
"The name sighandler_t for this data type is a GNU extension"

man 2 signal goes on to state:
"The use of sighandler_t is a GNU extension, exposed if _GNU_SOURCE is defined; glibc also defines (the BSD-derived) sig_t  if  _BSD_SOURCE (glibc 2.19 and earlier) or _DEFAULT_SOURCE (glibc 2.19 and later) is defined.  Without use of such a type, the declaration of signal() is the somewhat harder to read:
void ( *signal(int signum, void (*handler)(int)) ) (int);"

So is sticking with _GNU_SOURCE the best option?

> I think usually you don't need siginfo_t explicitly and because you don't
> assign the handlers to variables.

It is clear that signal() is deprecated and sigaction() should be used. From http://pubs.opengroup.org/onlinepubs/009695399/functions/sigaction.html :
"The sigaction() function supersedes the signal() function, and should be used in preference. In particular, sigaction() and signal() should not be used in the same process to control the same signal"
So I think signal() should be marked as deprecated in the VAPI and sigaction shown as the replacement. This helps anyone new coming to signals.

I hope to become a bit more familiar with signals before commenting on the current binding of sigaction and the use of the sigaction struct. I don't know if it is possible to bind void(*) (int) as its own delegate in the VAPI. This would avoid feature macros.
Comment 5 Michael 'Mickey' Lauer 2018-02-21 08:30:33 UTC
With bug 793444 fixed, we should be able to augment all uses of sighandler_t with feature_test_macro = "_GNU_SOURCE". While this works for all the functions, for some reason it doesn't get picked up when used for a struct field like that:

public struct sigaction_t {
  [CCode (feature_test_macro = "_GNU_SOURCE")]
  sighandler_t     sa_handler;

I wonder whether I did overlook something in the implementation of feature_test_macro?
Comment 6 Michael 'Mickey' Lauer 2018-02-21 09:25:32 UTC
commit c9fd5cdbb12b1978df5340576c2a4744ff4bd2a2
Author: Dr. Michael Lauer <mickey@vanille-media.de>
Date:   Wed Feb 21 10:21:29 2018 +0100

    posix: add feature_test_macro _GNU_SOURCE to sighandler_t

    https://bugzilla.gnome.org/show_bug.cgi?id=761975