Re: how to understand this CPP syntax?

Discussion in 'C Programming' started by Stefan Ram, Feb 15, 2010.

  1. Stefan Ram

    Stefan Ram Guest

    Joey Wang <> writes in comp.lang.c.moderated:
    >I have a problem understanding the following definitions in <signal.h>
    >#define SIG_ERR (void (*) ())-1
    >#define SIG_DFL (void (*) ())0
    >#define SIG_IGN (void (*) ())1
    >Are they the CPP's way of defining a function pointer (cuz SIG_ERR is
    >a func ptr)?
    >How to understand this syntax?
    >Can anyone guide me through this?


    The header files provided by an implementation are not
    bounded by the limits of portable C code, but free to use
    implementation-specified notations. A user of a
    C implementations is not supposed to understand his
    implementation's header files nor to modify them.

    #define usually just does text substitutions.
    The preprocessor usually is not aware of the structure of the
    C language proper. But an implementation possibly might even
    be free to change the meaning of #define for its own header
    files or standard macro names (although I never heard of this).
    Stefan Ram, Feb 15, 2010
    #1
    1. Advertising

  2. -berlin.de (Stefan Ram) writes:
    > Joey Wang <> writes in comp.lang.c.moderated:
    >>I have a problem understanding the following definitions in <signal.h>
    >>#define SIG_ERR (void (*) ())-1
    >>#define SIG_DFL (void (*) ())0
    >>#define SIG_IGN (void (*) ())1
    >>Are they the CPP's way of defining a function pointer (cuz SIG_ERR is
    >>a func ptr)?
    >>How to understand this syntax?
    >>Can anyone guide me through this?

    >
    > The header files provided by an implementation are not
    > bounded by the limits of portable C code, but free to use
    > implementation-specified notations. A user of a
    > C implementations is not supposed to understand his
    > implementation's header files nor to modify them.
    >
    > #define usually just does text substitutions.
    > The preprocessor usually is not aware of the structure of the
    > C language proper. But an implementation possibly might even
    > be free to change the meaning of #define for its own header
    > files or standard macro names (although I never heard of this).


    All true, but not entirely relevant to the question.

    First of all, the OP omitted some parentheses. The actual definitions
    are probably:

    #define SIG_ERR ((void (*) ())-1)
    #define SIG_DFL ((void (*) ())0)
    #define SIG_IGN ((void (*) ())1)

    Each definition is an integer constant expression converted,
    via a cast, to a pointer-to-function type. The cast is to type
    ``void(*)()'', i.e., pointer to function returning void.

    A modern implementation would probably define the
    parameter type:

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

    SIG_ERR, SIG_DFL, and SIG_IGN have to be function pointers, but
    they merely have to be unique values; it needn't be possible to
    call anything using their values. Converting a constant 0 to a
    pointer-to-function type yields a null pointer, so SIG_DFL happens
    to expand to an expression that evaluates to a null pointer value;
    (SIG_DFL == NULL) is true. Converting any other integer value to
    a pointer-to-function type yields some value that's not specified
    by the standard (I'm not sure whether it's implementation-defined
    or unspecified). The point is that, for the implementation for
    which the above definitions were written, the three expressions
    yield pointer values that are distinguishable from any pointer to
    an actual function.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Feb 15, 2010
    #2
    1. Advertising

  3. -berlin.de (Stefan Ram) writes:
    > Joey Wang <> writes in comp.lang.c.moderated:
    >>I have a problem understanding the following definitions in <signal.h>
    >>#define SIG_ERR (void (*) ())-1
    >>#define SIG_DFL (void (*) ())0
    >>#define SIG_IGN (void (*) ())1

    [snip]
    >
    > The header files provided by an implementation are not
    > bounded by the limits of portable C code, but free to use
    > implementation-specified notations.

    [...]

    Stefan, the original article was posted only to comp.lang.c.moderated.
    Why did you post your followup only to comp.lang.c, and why didn't you
    mention that you were changing newsgroups?

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Feb 15, 2010
    #3
    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. DrUg13
    Replies:
    1
    Views:
    459
    DrUg13
    Feb 10, 2004
  2. Alex Vinokur
    Replies:
    7
    Views:
    396
    Greg Comeau
    Nov 15, 2004
  3. Vinu
    Replies:
    9
    Views:
    594
  4. Wes Harrison
    Replies:
    3
    Views:
    2,289
    horahora.geo
    Jan 23, 2008
  5. www.hitechskill.com
    Replies:
    0
    Views:
    1,324
    www.hitechskill.com
    Apr 9, 2006
Loading...

Share This Page