interpret this code?

Discussion in 'C Programming' started by George, Jun 5, 2012.

  1. George

    George Guest

    I'm working on an old (comment-free) program, and finding some of the
    code is above my pay grade. I'd appreciate insight into what's going on
    with the segment below.

    -----------------
    #define SCRN_LIST \
    SCRN(Null) \
    SCRN(RYG) \
    SCRN(Fr00) \
    SCRN(LastN) \
    SCRN(DateTime) \

    #define INIT_LIST \
    INIT(Default) \
    INIT(LastN) \
    INIT(EvtLog) \
    INIT(EvtLogDetail) \

    typedef void (*VOID_FNC)(void);

    #define SCRN(symm) (const VOID_FNC)symm##ScrnFnc,
    #define INIT(symm) (const VOID_FNC)symm##InitFnc,
    const VOID_FNC ScrnFnc[] = {
    SCRN_LIST
    INIT_LIST
    };
    #undef SCRN
    #undef INIT

    // typical fnc

    void
    NullScrnFnc(void) { ... }
    -----------------

    I think the final result wants to be ...
    const void (*ScrnFnc[])() = {
    NullScrnFnc,
    RYGScrnFnc,
    ...
    DefaultInitFnc,
    LastNInitFnc,
    ...
    };

    Even assuming that's correct, I don't see how it gets there. I see that
    SCRN_LIST/INIT_LIST will cause ea of their listed arguments (Null, RYG,
    etc) to instantiate the 'SCRN'/'INIT' macros in the ScrnFnc[]
    declaration, But, ISTM, this would create something like (eg) ...
    void (*NullFnc)()


    Bonus points: I don't know how to 'read' the VOID_FNC typedef. I think
    that's a standard construct (ptr to void fnc?), but the logic of it
    eludes me.

    Thanks,
    George
     
    George, Jun 5, 2012
    #1
    1. Advertising

  2. George

    James Kuyper Guest

    On 06/05/2012 08:26 AM, George wrote:
    > I'm working on an old (comment-free) program, and finding some of the
    > code is above my pay grade. I'd appreciate insight into what's going on
    > with the segment below.
    >
    > -----------------
    > #define SCRN_LIST \
    > SCRN(Null) \
    > SCRN(RYG) \
    > SCRN(Fr00) \
    > SCRN(LastN) \
    > SCRN(DateTime) \
    >
    > #define INIT_LIST \
    > INIT(Default) \
    > INIT(LastN) \
    > INIT(EvtLog) \
    > INIT(EvtLogDetail) \
    >
    > typedef void (*VOID_FNC)(void);
    >
    > #define SCRN(symm) (const VOID_FNC)symm##ScrnFnc,
    > #define INIT(symm) (const VOID_FNC)symm##InitFnc,
    > const VOID_FNC ScrnFnc[] = {
    > SCRN_LIST
    > INIT_LIST
    > };
    > #undef SCRN
    > #undef INIT
    >
    > // typical fnc
    >
    > void
    > NullScrnFnc(void) { ... }
    > -----------------
    >
    > I think the final result wants to be ...
    > const void (*ScrnFnc[])() = {
    > NullScrnFnc,
    > RYGScrnFnc,
    > ...
    > DefaultInitFnc,
    > LastNInitFnc,
    > ...
    > };
    >
    > Even assuming that's correct, I don't see how it gets there. I see that
    > SCRN_LIST/INIT_LIST will cause ea of their listed arguments (Null, RYG,
    > etc) to instantiate the 'SCRN'/'INIT' macros in the ScrnFnc[]
    > declaration, But, ISTM, this would create something like (eg) ...
    > void (*NullFnc)()


    The expansion is actually

    (const VOID_FUNC)NullScrnFnc

    The equivalent without use of typedefs would be:

    (void(*)(void) const)NullScrnFnc

    In other words, it is an expression declaring that NullScrnFnc is an
    object of type (void(*)(void) const). A typedef is not simply a macro,
    which is why the const needs to be moved to the end of the cast. In an
    expression like "const int i", the keyword const modifies 'i'; the same
    is true in "const VOID_FUNC NullScrnFnc". However, if we were to write
    "const void(*)(void) NullScrnFnc", then the 'const' would (with
    undefined behavior - 6.7.3p9) modify the return type from the function.
    You need to move the 'const' to the end of the type specification for it
    to have the same meaning as it has in 'const VOID_FUNC'.

    > Bonus points: I don't know how to 'read' the VOID_FNC typedef. I think
    > that's a standard construct (ptr to void fnc?), but the logic of it
    > eludes me.


    The way to read a typedef is to first interpret it as an ordinary
    declaration, without the typedef. In this case, that would give us:

    void (*VOID_FNC)(void);

    What this would mean is that (*VOID_FUNC)() would be an expression of
    type void. The second pair of parentheses mean that (*VOID_FUNC) is a
    function. The second 'void' means that the function does not take any
    arguments. The '*' would indicate that VOID_FUNC is a pointer. Put that
    all together, and it would mean that VOID_FUNC is a pointer to a
    function taking no arguments and returning nothing.

    The effect of prefixing the declaration with "typedef" is that instead
    of VOID_FNC being the identifier for an object of that type, it's an
    alias for the type of such an object.
    --
    James Kuyper
     
    James Kuyper, Jun 5, 2012
    #2
    1. Advertising

  3. George

    BartC Guest

    "George" <> wrote in message
    news:...
    > I'm working on an old (comment-free) program, and finding some of the
    > code is above my pay grade.


    Or possibly just below it. Code shouldn't be unnecessarily obscure. Not if
    someone else needs to make head or tail of it.

    > I think the final result wants to be ...
    > const void (*ScrnFnc[])() = {
    > NullScrnFnc,
    > RYGScrnFnc,
    > ...
    > DefaultInitFnc,
    > LastNInitFnc,
    > ...
    > };
    >
    > Even assuming that's correct, I don't see how it gets there. I see that
    > SCRN_LIST/INIT_LIST will cause ea of their listed arguments (Null, RYG,
    > etc) to instantiate the 'SCRN'/'INIT' macros in the ScrnFnc[]
    > declaration, But, ISTM, this would create something like (eg) ...
    > void (*NullFnc)()


    I passed the code through a compiler option to generate the output of the
    preprocessor (-E on gcc). The output, with editing to improve the layout,
    is:

    const VOID_FNC ScrnFnc[] = {
    (const VOID_FNC)NullScrnFnc,
    (const VOID_FNC)RYGScrnFnc,
    (const VOID_FNC)Fr00ScrnFnc,
    (const VOID_FNC)LastNScrnFnc,
    (const VOID_FNC)DateTimeScrnFnc,
    (const VOID_FNC)DefaultInitFnc,
    (const VOID_FNC)LastNInitFnc,
    (const VOID_FNC)EvtLogInitFnc,
    (const VOID_FNC)EvtLogDetailInitFnc,
    };

    Now why couldn't it have looked like that in the first place?

    --
    Bartc
     
    BartC, Jun 5, 2012
    #3
  4. George <> writes:

    > I'm working on an old (comment-free) program, and finding some of the
    > code is above my pay grade. I'd appreciate insight into what's going on
    > with the segment below.
    >
    > -----------------
    > #define SCRN_LIST \
    > SCRN(Null) \
    > SCRN(RYG) \
    > SCRN(Fr00) \
    > SCRN(LastN) \
    > SCRN(DateTime) \
    >
    > #define INIT_LIST \
    > INIT(Default) \
    > INIT(LastN) \
    > INIT(EvtLog) \
    > INIT(EvtLogDetail) \
    >
    > typedef void (*VOID_FNC)(void);
    >
    > #define SCRN(symm) (const VOID_FNC)symm##ScrnFnc,
    > #define INIT(symm) (const VOID_FNC)symm##InitFnc,
    > const VOID_FNC ScrnFnc[] = {
    > SCRN_LIST
    > INIT_LIST
    > };
    > #undef SCRN
    > #undef INIT
    >
    > // typical fnc
    >
    > void
    > NullScrnFnc(void) { ... }
    > -----------------
    >
    > I think the final result wants to be ...
    > const void (*ScrnFnc[])() = {


    The type is actually

    void (*const ScrnFnc[])(void)

    Your () is not quite the same as (void), and the const refers to the
    whole pointer type -- i.e. the elements of the array are read-only. In
    your version, what is const is the returned type of the functions
    pointer to by the array elements and one never writes such things.
    Writing

    const int f(void);

    is pointless. Of course one often sees

    const char *f(void);

    or

    char const *f(void);

    but here what is const is the pointed-to type: f is a function returning
    a pointer to const char (or char const). A function returning a const pointer
    type is never written:

    char *const f(void);

    Once the programmer has defined the "pointer to function type" called
    VOID_FNC, making *that* const applies to the pointers in the array.

    Adding the the fact that ScrnFnc is an array makes the type harder to
    write but all C types are easy to readif you know the trick. This is
    such a common issue that I've put a page up about this:

    http://bsb.me.uk/c-types

    > NullScrnFnc,
    > RYGScrnFnc,
    > ...
    > DefaultInitFnc,
    > LastNInitFnc,
    > ...
    > };


    The result is actually

    const VOID_FNC ScrnFnc[] = {
    (const VOID_FNC)NullScrnFnc,
    (const VOID_FNC)RYGScrnFnc,
    ...
    (const VOID_FNC)DefaultInitFnc,
    (const VOID_FNC)LastNInitFnc,
    ...
    };

    because VOID_FNC is a typedef and so not "expanded", but I know what you
    meant.

    > Even assuming that's correct, I don't see how it gets there. I see that
    > SCRN_LIST/INIT_LIST will cause ea of their listed arguments (Null, RYG,
    > etc) to instantiate the 'SCRN'/'INIT' macros in the ScrnFnc[]
    > declaration, But, ISTM, this would create something like (eg) ...
    > void (*NullFnc)()


    Hmmm... not sure why you say that so I can't readily help. The typedef
    is not expanded, of course. Maybe that's part of the confusion?

    > Bonus points: I don't know how to 'read' the VOID_FNC typedef. I think
    > that's a standard construct (ptr to void fnc?), but the logic of it
    > eludes me.


    Does my linked page help with that?

    --
    Ben.
     
    Ben Bacarisse, Jun 5, 2012
    #4
  5. George

    Noob Guest

    BartC wrote:

    > I passed the code through a compiler option to generate the output of the
    > preprocessor (-E on gcc). The output, with editing to improve the layout,


    http://linux.die.net/man/1/indent
     
    Noob, Jun 5, 2012
    #5
  6. George

    Noob Guest

    Noob, Jun 5, 2012
    #6
  7. George

    Nick Bowler Guest

    On 2012-06-05 09:19:33 -0400, James Kuyper wrote:
    > On 06/05/2012 08:26 AM, George wrote:

    [...]
    >> typedef void (*VOID_FNC)(void);

    [...]
    > The expansion is actually
    >
    > (const VOID_FUNC)NullScrnFnc
    >
    > The equivalent without use of typedefs would be:
    >
    > (void(*)(void) const)NullScrnFnc


    This is a syntax error. I think you meant:

    (void(* const)(void))NullScrnFnc

    > In other words, it is an expression declaring that NullScrnFnc is an
    > object of type (void(*)(void) const).


    It doesn't declare anything, and that again is not a valid type name.

    > A typedef is not simply a macro, which is why the const needs to be moved to
    > the end of the cast. In an expression like "const int i", the keyword const
    > modifies 'i'; the same is true in "const VOID_FUNC NullScrnFnc". However, if
    > we were to write "const void(*)(void) NullScrnFnc",


    Another syntax error... I think you meant:

    const void(*NullScrnFnc)(void)

    > then the 'const' would (with undefined behavior - 6.7.3p9) modify the return
    > type from the function.


    Assuming the above correction is what you meant, C11 6.7.3p9 does not
    apply since (as you have stated) the qualifier applies to the return
    type (which is not a function type), not the function type itself. The
    only way to actually qualify a function type or an array type (and thus
    make 6.7.3p9 apply) is by using a typedef, as in:

    typedef void func_type(void);
    const func_type explode; /* qualified function type, UB by C11 6.7.3p9 */

    Of course, const-qualifying the return type of a function make little
    sense (especially if it's void!), but it is nevertheless valid.
     
    Nick Bowler, Jun 5, 2012
    #7
  8. George

    James Kuyper Guest

    On 06/05/2012 11:55 AM, Nick Bowler wrote:
    > On 2012-06-05 09:19:33 -0400, James Kuyper wrote:
    >> On 06/05/2012 08:26 AM, George wrote:

    > [...]
    >>> typedef void (*VOID_FNC)(void);

    > [...]
    >> The expansion is actually
    >>
    >> (const VOID_FUNC)NullScrnFnc
    >>
    >> The equivalent without use of typedefs would be:
    >>
    >> (void(*)(void) const)NullScrnFnc

    >
    > This is a syntax error. I think you meant:
    >
    > (void(* const)(void))NullScrnFnc


    You're right.

    >> In other words, it is an expression declaring that NullScrnFnc is an
    >> object of type (void(*)(void) const).

    >
    > It doesn't declare anything, and that again is not a valid type name.


    I got confused at one point, thinking this was occurring inside a
    parameter list for a function. When I corrected that misunderstanding, I
    failed to correct all of the writing I'd done based upon that
    misunderstanding.
     
    James Kuyper, Jun 5, 2012
    #8
  9. George

    George Guest

    Thanks to all who replied. My question is answered, and then some.
    Another step on the road to enlightenment, though it will take me a bit
    to digest.

    George
     
    George, Jun 6, 2012
    #9
    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. Aliki
    Replies:
    3
    Views:
    775
    LostAtC
    Sep 24, 2004
  2. Replies:
    6
    Views:
    897
  3. mike
    Replies:
    2
    Views:
    325
    Knute Johnson
    Jan 21, 2009
  4. Jason Quek

    how to interpret string as code?

    Jason Quek, Nov 10, 2005, in forum: Perl Misc
    Replies:
    9
    Views:
    142
    J├╝rgen Exner
    Nov 12, 2005
  5. Replies:
    4
    Views:
    145
Loading...

Share This Page