5

Argument of type void (*)(int) is incompatible with parameter of type __sighnd64_t

Below is my simple code:

#include <iostream>
#include <string>
#include <signal.h>
#include <ctype>
#include <stdlib.h>
#include <stdio.h>
typedef struct mystrcut
{

  int a;
  char *b;

} mystr;

void set_string ( char **, const char * );
void my_handler(int s)
{
    printf("Caught signal %d\n",s);
    exit(1);

}

int main()
{
    const std::string str1[] = {"hello1", "hello2"};
    char str2[50];
    size_t size1 = str1[1].size();
    cout << size1;
    memcpy (str2, str1[1].c_str(), size1);

    cout << str2;
    mystr *m = NULL;
    m = new mystrcut;
    m->a = 5;

    set_string(&m->b, "hello");

    cout << m->b;
    delete []m->b;
//    void (*prev_fn)(int);
    signal (SIGINT,my_handler);
    return 0;
}
void set_string ( char **a, const char *b)
{
    *a = new char [strlen(b)+1];
    strcpy (*a, b);
}

I am working on openvms. Can I avoid the compilation error by some kind of type casting? My compiler expects `__sighnd64_t __64_signal(int, __sighnd64_t);

Adding around the handler extern c has worked. Thanks

Sam
  • 71
  • 1
  • 4
  • That's strange because AFAIK `__sighnd64_t` is typedef'd to `void (*)(int)`. But there are other issues in your code... for example `cout` must be an undeclared identifier because you don't use `std::` – Armen Tsirunyan Jun 27 '11 at 10:40
  • You probably have to look in the file for your compiler (which one?), to see exactly what it expects for the `signal()` parameters. – Bo Persson Jun 27 '11 at 10:40
  • 2
    Sorry for the maybe stupid question, but do you have a compilation problem? on linux it compiles and works, adding properly std:: where needed. – dave Jun 27 '11 at 10:45
  • 2
    I don't see any problem with the call to `signal` either. But there's a very serious problem in the function he passes to `signal`; you're not allowed to call `printf`. (Also, if you're portability concerns only include Unix machines, you should be using `sigaction` rather than `signal`.) – James Kanze Jun 27 '11 at 11:04
  • What platform are you compiling to? – David Rodríguez - dribeas Jun 27 '11 at 11:20
  • 1
    Try declaring your handler as `extern "C"`. This is strictly speaking required by the standard. `gcc` does not enforce this, but some other compilers do. – n. m. could be an AI Jun 27 '11 at 13:30
  • can you copy exact error message from compiling (fully) – osgx Jun 27 '11 at 13:48
  • I've merged your two accounts together. [Please read this Faq entry about cookie-based accounts.](http://meta.stackexchange.com/questions/44557/why-should-i-register-my-account/1228) –  Jun 27 '11 at 15:44

1 Answers1

4

Signal handling is not a C++, but a C. This error is bit strange...

In such cases, try to use extern "C" around your handler (to define it as C function), as https://stackoverflow.com/users/775806/n-m said in comments. Modern <signal.h> from openvms already has extern "C" inside: http://wasd.vsm.com.au/conan/sys$common/syslib/decc$rtldef.tlb?key=SIGNAL&title=Library%20/sys$common/syslib/decc$rtldef.tlb&referer=http%3A/wasd.vsm.com.au/conan/sys$common/syshlp/helplib.hlb.

HP docs says only about C, not a C++.

Another doc says that signal handler (catcher) must be declared in C as

 void func(int signo);
Community
  • 1
  • 1
osgx
  • 90,338
  • 53
  • 357
  • 513
  • 3
    I do not believe you need to declare functions as `extern "C"` in order for them to be called from C code at all. I think you only need to do this if they are referred to by name from C code. Since a pointer to the signal handler is being passed, this means that it does not need to be declared `extern "C"`. – Omnifarious Jun 27 '11 at 13:55
  • 1
    @Sam: That is interesting. I'm wondering if the function call convention to use is part of the type on your system. – Omnifarious Jun 27 '11 at 16:03
  • 2
    @Omnifarious: this is called "language linkage" in the standard-speak, and it *is* a part of the type (Two function types with different language linkages are distinct types even if they are otherwise identical -- C++03 7.5 IIRC). Some compilers make the C and the C++ functions type-compatible, for better or worse. – n. m. could be an AI Jun 27 '11 at 17:26
  • @n.m.: Interesting. This is something I'll have to keep in mind from now on. I didn't know anybody did that. Thank you. – Omnifarious Jun 29 '11 at 04:46