what does this line mean? - Unix

This is a discussion on what does this line mean? - Unix ; typedef struct { int magic; CoreWindowStack *stack; UniqueContext *context; GlobalReaction context_reaction; } StackData; static DFBResult wm_process_input( CoreWindowStack *stack, void *wm_data, void *stack_data, const DFBInputEvent *event ) { StackData *data = stack_data; (void) data; D_ASSERT( stack != NULL ); D_ASSERT( wm_data ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: what does this line mean?

  1. what does this line mean?

    typedef struct {
    int magic;

    CoreWindowStack *stack;

    UniqueContext *context;

    GlobalReaction context_reaction;
    } StackData;

    static DFBResult
    wm_process_input( CoreWindowStack *stack,
    void *wm_data,
    void *stack_data,
    const DFBInputEvent *event )
    {
    StackData *data = stack_data;

    (void) data;

    D_ASSERT( stack != NULL );
    D_ASSERT( wm_data != NULL );
    D_ASSERT( stack_data != NULL );
    D_ASSERT( event != NULL );

    D_MAGIC_ASSERT( data, StackData );

    return DFB_OK;
    }


    Its from a source file, i can't understand why (void) data here?

    Thanks.
    Bin


  2. Re: what does this line mean?

    Bin Chen writes:

    > typedef struct {


    You should probably read this *again*:
    http://catb.org/esr/faqs/smart-questions.html

    > Its from a source file, i can't understand why (void) data here?


    Try removing it, and observe what new warnings compiler emits.

    Cheers,
    --
    In order to understand recursion you must first understand recursion.
    Remove /-nsp/ for email.

  3. Re: what does this line mean?

    In article <1191993956.468674.254630@57g2000hsv.googlegroups.c om>,
    Bin Chen wrote:

    > typedef struct {
    > int magic;
    >
    > CoreWindowStack *stack;
    >
    > UniqueContext *context;
    >
    > GlobalReaction context_reaction;
    > } StackData;
    >
    > static DFBResult
    > wm_process_input( CoreWindowStack *stack,
    > void *wm_data,
    > void *stack_data,
    > const DFBInputEvent *event )
    > {
    > StackData *data = stack_data;
    >
    > (void) data;
    >
    > D_ASSERT( stack != NULL );
    > D_ASSERT( wm_data != NULL );
    > D_ASSERT( stack_data != NULL );
    > D_ASSERT( event != NULL );
    >
    > D_MAGIC_ASSERT( data, StackData );
    >
    > return DFB_OK;
    > }
    >
    >
    > Its from a source file, i can't understand why (void) data here?


    My guess is that D_MAGIC_ASSERT is a debugging macro that may expand to
    nothing, depending on the setting of some other macro. (void)data
    prevents the compiler from warning that data is assigned but never used
    in this case.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  4. Re: what does this line mean?

    On Oct 9, 11:16 pm, Barry Margolin wrote:

    > My guess is that D_MAGIC_ASSERT is a debugging macro that may expand to
    > nothing, depending on the setting of some other macro. (void)data
    > prevents the compiler from warning that data is assigned but never used
    > in this case.


    Yep. Classic sign of a broken macro. A macro should evaluate or not
    evaluate its arguments exactly the same no matter what it expands to.
    Imagine what would happen if you passed this macro an argument with
    side effects!

    DS


  5. Re: what does this line mean?

    On 10 14 , 5 03 , David Schwartz wrote:
    > On Oct 9, 11:16 pm, Barry Margolin wrote:
    >
    > > My guess is that D_MAGIC_ASSERT is a debugging macro that may expand to
    > > nothing, depending on the setting of some other macro. (void)data
    > > prevents the compiler from warning that data is assigned but never used
    > > in this case.

    >
    > Yep. Classic sign of a broken macro. A macro should evaluate or not
    > evaluate its arguments exactly the same no matter what it expands to.
    > Imagine what would happen if you passed this macro an argument with
    > side effects!


    What is the side effects?



  6. Re: what does this line mean?

    On Oct 14, 4:52 pm, Bin Chen wrote:

    > > Yep. Classic sign of a broken macro. A macro should evaluate or not
    > > evaluate its arguments exactly the same no matter what it expands to.
    > > Imagine what would happen if you passed this macro an argument with
    > > side effects!

    >
    > What is the side effects?


    Imagine this:

    SOME_ASSERT_MACRO(i++!=0);

    If the macro is defined like this:

    #ifdef DEBUG
    #define SOME_ASSERT_MACRO(x) if(!(x)) Fatal(__FILE__, __LINE__)
    #else
    #define SOME_ASSERT_MACRO(x) while(0) do
    #endif

    Then if DEBUG is defined, 'i' gets incremented. If DEBUG is not
    defined, 'i' does not get incremented. That's definitely a very bad
    thing.

    DS


  7. Re: what does this line mean?

    On Sun, 14 Oct 2007 20:51:57 -0700, David Schwartz wrote:

    > On Oct 14, 4:52 pm, Bin Chen wrote:
    >
    >> > Yep. Classic sign of a broken macro. A macro should evaluate or not
    >> > evaluate its arguments exactly the same no matter what it expands to.
    >> > Imagine what would happen if you passed this macro an argument with
    >> > side effects!

    >>
    >> What is the side effects?

    >
    > Imagine this:
    >
    > SOME_ASSERT_MACRO(i++!=0);
    >
    > If the macro is defined like this:
    >
    > #ifdef DEBUG
    > #define SOME_ASSERT_MACRO(x) if(!(x)) Fatal(__FILE__, __LINE__) #else
    > #define SOME_ASSERT_MACRO(x) while(0) do #endif
    >
    > Then if DEBUG is defined, 'i' gets incremented. If DEBUG is not defined,
    > 'i' does not get incremented. That's definitely a very bad thing.


    This is fairly well known problem, and the usual suggestion is:

    _DON'T DO THAT THEN_

    ....outside libc. it's almost mandatory that macros be in all caps. (even
    more so if they evaluate arguments twice), so it's pretty much a
    non-problem IMO.

    This also allows things like:

    ASSERT(expensive_check(x));

    ....without having to wrap expensive_check() to something that
    disappears in production code.

    As to the OP's problem, I'd usually suggest only compiling with
    warnings+debugging or just optimizations ... so you don't need the
    (void)x; warts. If that fails using __attribute__((__used__)) is
    enough.

    --
    James Antill -- james@and.org
    C String APIs use too much memory? ustr: length, ref count, size and
    read-only/fixed. Ave. 44% overhead over strdup(), for 0-20B strings
    http://www.and.org/ustr/

  8. Re: what does this line mean?

    On Oct 15, 10:02 am, James Antill wrote:

    > > Then if DEBUG is defined, 'i' gets incremented. If DEBUG is not defined,
    > > 'i' does not get incremented. That's definitely a very bad thing.


    > This is fairly well known problem, and the usual suggestion is:
    >
    > _DON'T DO THAT THEN_


    Yes.

    > This also allows things like:
    >
    > ASSERT(expensive_check(x));
    >
    > ...without having to wrap expensive_check() to something that
    > disappears in production code.


    This is an argument not to evaluate the parameter. However, the
    example didn't use the parameter at all. The former is correct, the
    latter is broken.

    For example, consider:
    #define ASSERT(j) if (false && (j)); else (void) 0

    This is guaranteed not to evaluate 'j'. However, it will suppress
    bogus warnings about 'j' not being used.

    DS


  9. Re: what does this line mean?

    David Schwartz wrote:

    > This is an argument not to evaluate the parameter. However, the
    > example didn't use the parameter at all. The former is correct, the
    > latter is broken.
    >
    > For example, consider:
    > #define ASSERT(j) if (false && (j)); else (void) 0
    >
    > This is guaranteed not to evaluate 'j'. However, it will suppress
    > bogus warnings about 'j' not being used.


    It will suppress *some* bogous warnings but may replace by different
    bogous warnings such as "condition is always false" or "code is never
    reached".

    --
    If you've a question that doesn't belong to Usenet, contact me at


  10. Re: what does this line mean?

    On Oct 21, 3:10 am, "André Gillibert"
    wrote:

    > > For example, consider:
    > > #define ASSERT(j) if (false && (j)); else (void) 0


    > > This is guaranteed not to evaluate 'j'. However, it will suppress
    > > bogus warnings about 'j' not being used.


    > It will suppress *some* bogous warnings but may replace by different
    > bogous warnings such as "condition is always false" or "code is never
    > reached".


    Oddly, I've never gotten a warning from the macro. It evolved to that
    after numerous problems of varying severity in previous macros. You
    are certainly correct that in principle a compiler could justifiably
    emit such warnings, but I've never had it happen.

    It may be that they special case 'false &&' because it is commonly
    used for this purpose and save the warning for things that are more
    subtle, such as 'unsigned j' if(j<0)...'.

    DS


+ Reply to Thread