Signal Handling - Are they part of ANSI C?

Discussion in 'C Programming' started by Stanley S, Dec 21, 2005.

  1. Stanley S

    Stanley S Guest

    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, Dec 21, 2005
    #1
    1. Advertising

  2. Stanley S

    Richard Bos Guest

    "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
    Richard Bos, Dec 21, 2005
    #2
    1. Advertising

  3. Stanley S

    Flash Gordon Guest

    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, Dec 21, 2005
    #3
  4. Stanley S

    pemo Guest

    "Flash Gordon" <> wrote in message
    news:-gordon.me.uk...
    > 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'.
    pemo, Dec 21, 2005
    #4
  5. In article <-gordon.me.uk>,
    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
    Dave Vandervies, Dec 21, 2005
    #5
  6. Stanley S

    Richard Bos Guest

    "pemo" <> wrote:

    > "Flash Gordon" <> wrote in message
    > news:-gordon.me.uk...
    > > 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, Dec 21, 2005
    #6
  7. Stanley S

    pemo Guest

    "Richard Bos" <> wrote in message
    news:4all.nl...
    > "pemo" <> wrote:
    >
    >> "Flash Gordon" <> wrote in message
    >> news:-gordon.me.uk...
    >> > 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' :)
    pemo, Dec 21, 2005
    #7
  8. Stanley S

    Simon Biber Guest

    Dave Vandervies wrote:
    > In article <-gordon.me.uk>,
    > 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.
    Simon Biber, Dec 22, 2005
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    1
    Views:
    469
  2. Replies:
    11
    Views:
    1,042
    Keith Thompson
    Apr 28, 2008
  3. Frank Iannarilli

    pre-ansi to ansi c++ conversion?

    Frank Iannarilli, Jul 21, 2009, in forum: C++
    Replies:
    2
    Views:
    399
  4. Peter
    Replies:
    34
    Views:
    1,902
    James Kanze
    Oct 17, 2009
  5. Sandman

    ANSI colors and the space they take.

    Sandman, Dec 31, 2003, in forum: Perl Misc
    Replies:
    14
    Views:
    641
    Michele Dondi
    Jan 12, 2004
Loading...

Share This Page