«

Hi,

Are Signal Handling part of ANSI C?

I am not able to find any reference of Sig Handling in Stephen Prata's
"C Primer Plus".

The usage of signals is to trap errors I guess. (It looks similiar to
the concept of try-catch to me.) It seems to relate more to nix OS. Are
signals handling part of Windows too?

"Stanley S" <> wrote:

> Are Signal Handling part of ANSI C?

Yes, but not in a very flexible way. <signal.h> declares:

- sig_atomic_t, which is a type definition for use in signal functions
(and which is, basically, the only type that _can_ be used safely in
signal functions);
- the macros SIG_DFL, SIG_ERR and SIG_IGN, which can be passed to
signal() to designate default signal handling, an error during the
execution of signal() itself, and no signal handling;
- SIGABRT, SIGFPE, SIGILL, SIGINT, SIGSEGV and SIGTERM, which represent
the only signals ISO C recognises;
- signal(), which can be used to set the signal handler (and retrieve
the current one) for a specific signal; and
- raise(), which raises a signal.

Note that signal functions you write yourself are strongly restricted in
what they can do without causing undefined behaviour. You cannot refer
to any static object except by flagging a volatile sig_atomic_t (and you
can't access previously allocated objects, either, since you will have
no way to get at them except through a static object...); and you can't
call any Standard library function except abort(), _Exit(), or signal()
on the signal which was raised.
So basically, ISO C signals can set a (or several) flags. That _can_ be
turned into something useful, but it requires some work.

> I am not able to find any reference of Sig Handling in Stephen Prata's
> "C Primer Plus".

I wouldn't necessarily expect a Primer to cover signal handling. It is a
hairy business.

> The usage of signals is to trap errors I guess.

Amongst others.

I gather POSIX signals are more powerful, but ask in
comp.unix.programmer for POSIX.

Richard

Stanley S wrote:
> Hi,
>
> Are Signal Handling part of ANSI C?

There is limited signal handling in standard C and it is easy to step
beyond the realms of ANSI/ISO standard C when doing signal handling.

> I am not able to find any reference of Sig Handling in Stephen Prata's
> "C Primer Plus".

Even K&R2 only has half a page, and that is in the description of the
standard library rather than in the main body of the book. However, I
would still recommend you get K&R2 as both a good reference and an
additional teaching book.

> The usage of signals is to trap errors I guess. (It looks similiar to
> the concept of try-catch to me.)

Not really.

1) Signals can (and often are) generated by things outside your program,
one common instance being someone trying to kill your program.
2) There is very little the standard allows you to do in a signal
handler.
3) When the signal handler returns, the program resumes from the point
where the signal interrupted it. A real problem if the signal was
indicating an arithmetic error such as division by zero.

> It seems to relate more to nix OS. Are
> signals handling part of Windows too?

They are part of standard C so they are part of Windows. However, Unix
uses signals a lot more than Windows.

For details on how Unix uses signals you will have to ask on a Unix
group such as comp.unix.programmer (after reading their FAQ) and for
Windows (including the other mechanisms Windows provides for doing
things that in Unix are done with signals).
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

"Flash Gordon" <> wrote in message
news:...
> Stanley S wrote:
>> Hi,
>>
>> Are Signal Handling part of ANSI C?
>

<snip>

>
> 1) Signals can (and often are) generated by things outside your program,
> one common instance being someone trying to kill your program.

Just to add ...

like when someone's bashing Ctrl + C, and certainly *not* when they're
bashing 'End Process'.

In article <>,
Flash Gordon <> wrote:
>Stanley S wrote:

> > It seems to relate more to nix OS. Are
>> signals handling part of Windows too?
>
>They are part of standard C so they are part of Windows. However, Unix
>uses signals a lot more than Windows.

Windows also handles signals (at least SIGINT, which is the only one I've
tried to use in a program intended to run on Windows) in a way that's
Completely Weird from a unix-ish point of view, while still being (as
far as I can tell) perfectly acceptable according to the C definition.
So if you're interested in learning about how to work with signals in C
(as opposed to how to work with them in C-on-your-platform-of-choice,
which is probably more useful for getting stuff done, even though it
does tie you down to that platform) you should take a close look at how
Windows handles them, even if you're not planning to use Windows.


dave

--
Dave Vandervies
Well, either that, or [the cats are] smarter at concealing & disposing of the
medicine than I am at catching them at it, in which case they're smart enough
to sort out their own damn medical problems. --Lionel in the SDM

"pemo" <> wrote:

> "Flash Gordon" <> wrote in message
> news:...
> > 1) Signals can (and often are) generated by things outside your program,
> > one common instance being someone trying to kill your program.
>
> Just to add ...
>
> like when someone's bashing Ctrl + C, and certainly *not* when they're
> bashing 'End Process'.

You do not know that at all. It may be that way on your favourite toy
system, but it's not guaranteed to work like that on a real OS.

In fact, I'd expect that a system-defined signal is _exactly_ what a C
program will see, at first, when it is killed on certain OSes.

Richard

"Richard Bos" <> wrote in message
news:...
> "pemo" <> wrote:
>
>> "Flash Gordon" <> wrote in message
>> news:...
>> > 1) Signals can (and often are) generated by things outside your
>> > program,
>> > one common instance being someone trying to kill your program.
>>
>> Just to add ...
>>
>> like when someone's bashing Ctrl + C, and certainly *not* when they're
>> bashing 'End Process'.
>
> You do not know that at all. It may be that way on your favourite toy
> system, but it's not guaranteed to work like that on a real OS.
>
> In fact, I'd expect that a system-defined signal is _exactly_ what a C
> program will see, at first, when it is killed on certain OSes.

Indeed, I do not hold this to be a *universal truth* - but, at the same
time, I do not hold much of anything to be likewise - until proved
otherwise. Go on, 'Make my day'

Dave Vandervies wrote:
> In article <>,
> Flash Gordon <> wrote:
>
>>Stanley S wrote:
>
>
>>>It seems to relate more to nix OS. Are
>>>signals handling part of Windows too?
>>
>>They are part of standard C so they are part of Windows. However, Unix
>>uses signals a lot more than Windows.
>
>
> Windows also handles signals (at least SIGINT, which is the only one I've
> tried to use in a program intended to run on Windows) in a way that's
> Completely Weird from a unix-ish point of view, while still being (as
> far as I can tell) perfectly acceptable according to the C definition.
> So if you're interested in learning about how to work with signals in C
> (as opposed to how to work with them in C-on-your-platform-of-choice,
> which is probably more useful for getting stuff done, even though it
> does tie you down to that platform) you should take a close look at how
> Windows handles them, even if you're not planning to use Windows.

That's because C signals are *the* native signalling mechanism on Unix,
used to signal such things as interrupt (Ctrl-C), kill process, hang up
terminal, change window size, etc.

Windows has its own ways of interprocess messaging that don't involve C
signals. The implementation of C signals on Windows is therefore little
more than the minimum required to conform to the Standard.

--
Simon.