SIG_DFL what for?

SIG_DFL what for?

Post by Pratik Pari » Sun, 23 Mar 2003 22:03:35



What is the use of calling:
signal (SIGSEGV,SIG_DFL);

Even if it is not written the default action will be taken! Right?

I have a book, which says:
The SIG_IGN and SIG_DFL are manifest constants defined in the
<signal.h> header:

#define SIG_DFL void(*)(int)0
#define SIG_IGN void(*)(int)1

But if you substitute SIG_DFL with void(*)(int)0 it doesn't work. Why?

Could someone help me understand this prototype?
void(*signal(int signal_num, void (*handler)(int)))(int);

What does it mean when you can actually call the function with
something as simple as:
signal (SIGTERM,catch_sig);

Thanks,
Pratik.

 
 
 

SIG_DFL what for?

Post by d4.. » Sun, 23 Mar 2003 22:13:41


|What is the use of calling:
|signal (SIGSEGV,SIG_DFL);
|
|Even if it is not written the default action will be taken! Right?

Maybe it was set to a non-default earlier and you want to reset it?

|I have a book, which says:
|The SIG_IGN and SIG_DFL are manifest constants defined in the
|<signal.h> header:
|
|#define SIG_DFL        void(*)(int)0
|#define SIG_IGN        void(*)(int)1

Surely a mistake, it should be a cast, like (void(*)(int))0. See
expansion of SIG_DFL in gcc's include files, which actually uses a type
called __sighandler_t and is a bit more elaborate.

|But if you substitute SIG_DFL with void(*)(int)0 it doesn't work. Why?
|
|Could someone help me understand this prototype?
|void(*signal(int signal_num, void (*handler)(int)))(int);

Ah, you can't say you understand C declarations until you have nutted
out this one for yourself. :-)

 
 
 

SIG_DFL what for?

Post by Jens.Toerr.. » Sun, 23 Mar 2003 23:24:48



> What is the use of calling:
> signal (SIGSEGV,SIG_DFL);
> Even if it is not written the default action will be taken! Right?

When you did set it to something else but then want to switch back
to the default action SIG_DFL can be quite handy.

Quote:> I have a book, which says:
> The SIG_IGN and SIG_DFL are manifest constants defined in the
> <signal.h> header:
> #define SIG_DFL    void(*)(int)0
> #define SIG_IGN    void(*)(int)1
> But if you substitute SIG_DFL with void(*)(int)0 it doesn't work. Why?

First of all, what "doesn't work"? And this is the way it is defined
on some systems, but AFAIK there's nowhere written is stone that it
needs to be defined this way. E.g. SUSV3 just writes that both must be
constant expressions whose values match no declarable function, but
that's all. SIG_DFL and SIG_IGN are defined so you don't need to know.

Quote:> Could someone help me understand this prototype?
> void(*signal(int signal_num, void (*handler)(int)))(int);
> What does it mean when you can actually call the function with
> something as simple as:
> signal (SIGTERM,catch_sig);

The signal() function returns a pointer to the proviously used
signal handler function, which itself is a function that takes
a single int argument and returns void. So, when we leave out the
arguments of signal() it would be declared as

void ( *signal )( int )

The parentheses around *signal are important, without them it
would mean that signal() is a function that takes an int and
returns a void pointer. With the parentheses it means that
signal is a pointer to a function that takes an int and
returns void.

Now, the signal() function is a function that takes two arguments,
an int and a pointer to a signal handler function (that again
returns void and takes an int argument. So, without the return
value the declaration of signal() would be

signal( int, void ( *sighandler )( int ) )

Finally, we have to conmbine this and get

void ( *signal( int, void ( *sighandler )( int ) ) )( int )

You can make things easier for yourself if you use an additional
typedef:

typedef void ( *sighandler_t )( int );

That declares sighandler_t to represent a pointer to a function that
returns void and has an int argument, which is just the type of the
return value of the signal() function and the type of its second
argument. With this you can write the declaration of signal() as

sighandler_t signal( int, sighandler_t );

i.e. signal() is a function of two arguments, an int (the signal number)
and a pointer to a signal handler function (the one that is to be used
for the signal), and returns a pointer to a signal handler function (the
one that has been used until now for the signal).

When you now write

Quote:> signal (SIGTERM,catch_sig);

you set up a new signal handler, catch_sig, for SIGTERM and throw
away the return value, that would be pointing to the function that
has been dealing with SIGTERM signals until now.

Welcome to the interesting ways you do function declarations in C.
In principle it's logical, but it takes quite a bit of getting used
to ;-)
                                     Regards, Jens
--
      _  _____  _____

  _  | |  | |    | |
 | |_| |  | |    | |          http://www.physik.fu-berlin.de/~toerring
  \___/ens|_|homs|_|oerring

 
 
 

SIG_DFL what for?

Post by Pratik Parik » Tue, 25 Mar 2003 22:52:14



Quote:> typedef void ( *sighandler_t )( int );

I have a book which uses the following typedef:

typedef void Sigfunc(int);

I am not able to understand the typedef itself.

Sigfunc(int) seems to be a function prototype more than an identifier, how
can that be used?

If you could help me I will be very greatful.

Pratik.

 
 
 

SIG_DFL what for?

Post by Jens.Toerr.. » Wed, 26 Mar 2003 03:40:48





>> typedef void ( *sighandler_t )( int );
> I have a book which uses the following typedef:
> typedef void Sigfunc(int);
> I am not able to understand the typedef itself.

This makes Sigfunc a new type and the type is function that
returns void and takes a single int argument. It's similar to
the typedef for sighandler_t, but it's not explicitely a pointer
to such a function but mor like the function itself. But in C
the address of a function and the function itself are usually
interchangeable. For example if 'func' is a pointer to a function,
you can call the function it points to both by using

func();

and

*func();

And, in cases where the address of a function is required (like in
the signal() function) you can both use the function name or the
function name with the address operator '&' in front of it. I think
it's just a question of taste what to use.

Quote:> Sigfunc(int) seems to be a function prototype more than an identifier, how
> can that be used?

When you put 'typedef' in front of it means something else. It's similar
to

typedef int abc;

The "int abc;" bit looks quite a lot like a variable declaration, but
when you put a 'typedef' in front of it the meaning changes, abc is
now a new name for int.
                                  Regards, Jens
--
      _  _____  _____

  _  | |  | |    | |
 | |_| |  | |    | |          http://www.physik.fu-berlin.de/~toerring
  \___/ens|_|homs|_|oerring

 
 
 

SIG_DFL what for?

Post by Pratik Parik » Wed, 26 Mar 2003 04:28:01



Quote:> ...I think
> it's just a question of taste what to use.

Thanks.

Quote:> > Sigfunc(int) seems to be a function prototype more than an identifier,
how
> > can that be used?

> When you put 'typedef' in front of it means something else. It's similar
> to

> typedef int abc;

> The "int abc;" bit looks quite a lot like a variable declaration, but
> when you put a 'typedef' in front of it the meaning changes, abc is
> now a new name for int.

  typedef (keyword)
 ???????????????????
Assigns the symbol name <identifier> to the data type definition <type
definition>.

 Syntax:  typedef <type definition> <identifier> ;

 Examples:
  t typedef unsigned char byte;
  t typedef char str40[41];
  t typedef struct {
      double re, im;
    } complex;
---
Turbo C++ documentation, help.

I feel that this may not be accurate.
typedef void Sigfunc(int);

typedef-<keyword>
void-<type definition>
Sigfunc(int)-<identifier>

How can Sigfunc(int) be a valid identifier?

 
 
 

SIG_DFL what for?

Post by Jens.Toerr.. » Wed, 26 Mar 2003 04:58:41



>  Syntax:  typedef <type definition> <identifier> ;
>  Examples:
>   t typedef unsigned char byte;
>   t typedef char str40[41];
>   t typedef struct {
>       double re, im;
>     } complex;
> ---
> Turbo C++ documentation, help.

Take care, C and C++ are two different languages! There are similarities
but they differ in many aspects.

Quote:> I feel that this may not be accurate.
> typedef void Sigfunc(int);
> typedef-<keyword>
> void-<type definition>
> Sigfunc(int)-<identifier>
> How can Sigfunc(int) be a valid identifier?

Well, the type definition here consists of both the void and the (int)
bits and Sigfunc is the indentifier. And since Sigfunc is supposed to
be a new name of a function type the (int) bit must come after the
identifier, otherwise it wouldn't look like a function. In the same way
for a typedef like

typedef void ( *sighandler_t )( int );

The void ( * )( int )

is the type definition and sighandler_t is the new name. And for

typedef int ( *a )[ 10 ];

a is the new name for a pointer to an array of 10 ints, so also
here there's stuff following the identifier.

Even in the examples above you have

typedef char str40[41];

which makes str40 a new name for an array of 41 chars, so writing

str40 xxx;

is identical to

char xxx[ 41 ];

So the simple rule

   typedef <type definition> <identifier> ;

doesn't catch all the cases, at least if you try to use it literally.

But if you want to make real sure I would recommend to ask this in
comp.lang.c where the real C experts can be found. In this group
it's getting quite a bit off-topic, this is a C syntax question,
nothing about system development for Linux anymore.

                                   Regards, Jens
--
      _  _____  _____

  _  | |  | |    | |
 | |_| |  | |    | |          http://www.physik.fu-berlin.de/~toerring
  \___/ens|_|homs|_|oerring

 
 
 

SIG_DFL what for?

Post by Pratik Parik » Thu, 27 Mar 2003 01:37:14



> Take care, C and C++ are two different languages! There are similarities
> but they differ in many aspects.

Are typdefs different in the two languages as well? :(

Quote:> But if you want to make real sure I would recommend to ask this in
> comp.lang.c where the real C experts can be found. In this group
> it's getting quite a bit off-topic, this is a C syntax question,
> nothing about system development for Linux anymore.

Yes. I agree.

Thanks,
Pratik.

I don't know why but the more I try to understand it, things seem to get
worse :(