warning: argument is incompatible with prototype: arg #2 - SCO

This is a discussion on warning: argument is incompatible with prototype: arg #2 - SCO ; I am getting this warning several times when compiling a program under SCO's native compiler: "interp.c", line 1768: warning: argument is incompatible with prototype: arg #2 (The line number and file name are obviously not the same in each warning, ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: warning: argument is incompatible with prototype: arg #2

  1. warning: argument is incompatible with prototype: arg #2

    I am getting this warning several times when compiling a program under
    SCO's native compiler:

    "interp.c", line 1768: warning: argument is incompatible with prototype: arg #2

    (The line number and file name are obviously not the same in each
    warning, but it does occur several times in this particular file.)

    The line in the file causing the warning is:

    (void) signal(SIGFPE, eval_fpe);

    The eval_fpe() function is defined in the same file, and begins like
    this:

    #ifdef SIGVOID
    void
    #else
    int
    #endif
    eval_fpe() /* Trap for FPE errors in eval */
    {

    (If you need to see the rest of the function, let me know, but I doubt
    that it's relevant.)

    Other, similar, calls to the signal() function in the same file issue no
    warnings, and it appears that the functions being installed as signal
    handlers use the same method of typing. Also, I don't see these warnings
    when compiling with gcc on Linux. I didn't write this program, but I have
    taken up maintaining it, and I would like to eliminate these warnings on
    SCO.

    By the way, I have other problems when compiling with gcc on SCO, but I'm
    trying to fix one thing at a time. In spite of the warnings, it at least
    compiles with the native compiler. Also, in case it matters, this is the
    output of uname -a:

    SCO_SV deepthought 3.2 5.0.6 i386

    and of cc -V:

    SCO UNIX Development System Release 5.2.0A 03Jan03
    Usage: cc [ options ] files ...

    Thanks in advance.

    Chuck


  2. Re: warning: argument is incompatible with prototype: arg #2

    Chuck Martin wrote:

    > I am getting this warning several times when compiling a program under
    > SCO's native compiler:
    >
    > "interp.c", line 1768: warning: argument is incompatible with prototype: arg #2
    >
    > (The line number and file name are obviously not the same in each
    > warning, but it does occur several times in this particular file.)
    >
    > The line in the file causing the warning is:
    >
    > (void) signal(SIGFPE, eval_fpe);
    >
    > The eval_fpe() function is defined in the same file, and begins like
    > this:
    >
    > #ifdef SIGVOID
    > void
    > #else
    > int
    > #endif
    > eval_fpe() /* Trap for FPE errors in eval */
    > {


    The prototype for signal() in says:

    extern void (*signal(int, void(*)(int)))(int);
    ^^^^^^^^^^^^
    The underlined portion means that the second argument is a pointer to a
    function that returns `void', and has an `int' argument. The eval_fpe()
    definition above is a function that has no argument.

    > Other, similar, calls to the signal() function in the same file issue no
    > warnings, and it appears that the functions being installed as signal
    > handlers use the same method of typing. Also, I don't see these warnings
    > when compiling with gcc on Linux. I didn't write this program, but I have
    > taken up maintaining it, and I would like to eliminate these warnings on
    > SCO.


    Do the other functions passed to signal() also have no arguments?

    >Bela<


  3. Re: warning: argument is incompatible with prototype: arg #2

    Bela Lubkin wrote:

    > > Other, similar, calls to the signal() function in the same file issue no
    > > warnings, and it appears that the functions being installed as signal
    > > handlers use the same method of typing. Also, I don't see these warnings
    > > when compiling with gcc on Linux. I didn't write this program, but I have
    > > taken up maintaining it, and I would like to eliminate these warnings on
    > > SCO.

    >
    > Do the other functions passed to signal() also have no arguments?


    Yes. Here is another statement in the same file:

    (void) signal(SIGFPE, doquit);

    The prototype for doquit() at the top of the file looks like this:

    #ifdef SIGVOID
    void doquit();
    #else
    int doquit();
    #endif

    The actual doquit() function is found in another file, and starts like this:

    #ifdef SIGVOID
    void
    #else
    int
    #endif
    doquit()
    {

    The only difference between the two that I can see is that the eval_fpe()
    function is in the same file, but the doquit() function is in another file
    and just has a function prototype in the same file.

    Hmm... A thought just occured to me. The eval_fpe() function doesn't
    appear to have a prototype. Could that be the problem? I'll try that
    later today when I get the chance.

    Chuck


  4. Re: warning: argument is incompatible with prototype: arg #2

    Bela Lubkin wrote:
    >No, that isn't the problem. The problem is as I said, but there's
    >another detail. The doquit() prototype above is a pre-ANSI prototype
    >that doesn't describe the function's arguments, only its return value.
    >The compiler can't tell, based on that prototype, that the function is
    >inappropriate because it takes no argument. If the prototype was more
    >specific:
    >
    > void doquit(void);


    Okay, that makes sense. This program wasn't originally ANSI C, but I
    converted it, and I wasn't sure if I got everything (or even knew enough
    about the differences to get it all). Thanks.

    >The POSIX standard and all the modern Unices I could find man pages for
    >specify the signal handler function as taking an `int' argument. (Man
    >pages for SunOS 4.1.3 and Ultrix 4.2 -- not modern -- specified the
    >signal handler as taking several arguments, the first of which was an
    >`int'.) The correct fix for this problem is to declare and define all
    >signal handler functions as taking an `int' argument. The function is
    >passed the number of the signal being raised; you can call the arg
    >`sig_received' or something like that. The handler doesn't actually
    >have to look at it.
    >
    >e.g.:
    >
    > void
    > doquit(int sig_received)
    > {
    > /*
    > * `sig_received' presumably has the value SIGQUIT, or you could
    > * check it if you've hooked this function up to multiple signals...
    > */
    > ...
    > }


    Thanks Bela. I'll try that (and you were right - adding a prototype for
    eval_fpe() didn't help).

    Chuck


+ Reply to Thread