Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.unix.programmer > #14072
| 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.
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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