Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.unix.programmer > #14072

Re: Question about Linux/gcc and the signal() function prototype.

From Kaz Kylheku <864-117-4973@kylheku.com>
Newsgroups comp.unix.programmer, comp.lang.c
Subject Re: Question about Linux/gcc and the signal() function prototype.
Date 2022-11-28 00:43 +0000
Organization A noiseless patient Spider
Message-ID <20221127164105.872@kylheku.com> (permalink)
References <tlq9hg$fuhb$1@news.xmission.com> <ygazgcftf5r.fsf@akutech.de> <tlqce3$fuhb$2@news.xmission.com> <87lenwfuq4.fsf@doppelsaurus.mobileactivedefense.com> <tlvncc$im4v$1@news.xmission.com>

Cross-posted to 2 groups.

Show all headers | View raw


On 2022-11-27, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <87lenwfuq4.fsf@doppelsaurus.mobileactivedefense.com>,
> Rainer Weikusat  <rweikusat@talktalk.net> wrote:
>>gazelle@shell.xmission.com (Kenny McCormack) writes:
>>
>>[sighandler_t confusion]
>>
>>> All of this seems to be an artifact of the fact that functions and pointers
>>> to functions are (basically) the same thing.  This isn't true for any other
>>> type of object.
>>
>>It's basically the same as with array types: An object which has a function
>>type is automatically converted to a pointer to a function when used as
>>argument of something. But they're nevertheless distinct. Stevens uses
>>
>>typedef void sighandler(int);
>>sighandler *signal(int, sighandler *);
>>
>>in newer editions of APUE.
>
> Yes.  That makes more sense.
>
> Probably won't ever get fixed, though.

With sighandler defined that way, you can do this:

  sighandler myhandler; // forward declaration of your handler

  void myhandler(int)   // ... but no way of using sighandler for defining
  {
  }

It has little value compared to just making a typedef for the pointer.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

Back to comp.unix.programmer | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Question about Linux/gcc and the signal() function prototype. gazelle@shell.xmission.com (Kenny McCormack) - 2022-11-25 11:39 +0000
  Re: Question about Linux/gcc and the signal() function prototype. Ralf Fassel <ralfixx@gmx.de> - 2022-11-25 13:03 +0100
    Re: Question about Linux/gcc and the signal() function prototype. gazelle@shell.xmission.com (Kenny McCormack) - 2022-11-25 12:28 +0000
      Re: Question about Linux/gcc and the signal() function prototype. Nicolas George <nicolas$george@salle-s.org> - 2022-11-25 13:05 +0000
        Re: Question about Linux/gcc and the signal() function prototype. gazelle@shell.xmission.com (Kenny McCormack) - 2022-11-25 14:01 +0000
      Re: Question about Linux/gcc and the signal() function prototype. scott@slp53.sl.home (Scott Lurndal) - 2022-11-25 16:57 +0000
      Re: Question about Linux/gcc and the signal() function prototype. Rainer Weikusat <rweikusat@talktalk.net> - 2022-11-27 12:27 +0000
        Re: Question about Linux/gcc and the signal() function prototype. gazelle@shell.xmission.com (Kenny McCormack) - 2022-11-27 13:06 +0000
          Re: Question about Linux/gcc and the signal() function prototype. Kaz Kylheku <864-117-4973@kylheku.com> - 2022-11-28 00:43 +0000
            Re: Question about Linux/gcc and the signal() function prototype. Richard Damon <Richard@Damon-Family.org> - 2022-11-27 21:39 -0500
            Re: Question about Linux/gcc and the signal() function prototype. Rainer Weikusat <rweikusat@talktalk.net> - 2022-11-28 11:47 +0000

csiph-web