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

Groups > comp.unix.programmer > #14074

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

Cross-posted to 2 groups.

Show key headers only | View raw

Kaz Kylheku <864-117-4973@kylheku.com> writes:
> 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.

This calls the following "famous wast lard" to mind (from the GLib
documentation)

typedef void *gpointer;

Gpointer is the GLib way of declaring a pointer to void. It looks better
than void * and is easier to use.

For people who don't belong to the I-have-to-use-C-but-hate-it!!1
faction, pointers are declared by suffixing a base type with *. Hence,
creating a typedef for the function type and deriving a pointer type
from that by suffixing it with * is consistent with the type system of
the language in general while using typedef to hide the * isn't.

Back to comp.unix.programmer | Previous | Next — Previous 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