Unix Programming - what does this line mean?

Author

what does this line mean?

Bin Chen

2007-10-10, 4:20 am

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

Paul Pluzhnikov

2007-10-10, 4:20 am

Bin Chen <binary.chen@gmail.com> 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.

Barry Margolin

2007-10-10, 4:20 am

In article <1191993956.468674.254630@57g2000hsv.googlegroups.com>,
Bin Chen <binary.chen@gmail.com> 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 ***

David Schwartz

2007-10-13, 7:09 pm

On Oct 9, 11:16 pm, Barry Margolin <bar...@alum.mit.edu> 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

Bin Chen

2007-10-14, 7:09 pm

On 10 14 , 5 03 , David Schwartz <dav...@webmaster.com> wrote:
> On Oct 9, 11:16 pm, Barry Margolin <bar...@alum.mit.edu> 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?

David Schwartz

2007-10-15, 4:19 am

On Oct 14, 4:52 pm, Bin Chen <binary.c...@gmail.com> wrote:

>
> 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

James Antill

2007-10-15, 7:11 pm

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

> On Oct 14, 4:52 pm, Bin Chen <binary.c...@gmail.com> wrote:
>
>
> 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/

David Schwartz

2007-10-15, 7:11 pm

On Oct 15, 10:02 am, James Antill <james-netn...@and.org> wrote:

[color=darkred]
> 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

André Gillibert

2007-10-21, 8:07 am

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
<tabkanDELETETHISnaz@yahoDELETETHATo.fr>

David Schwartz

2007-10-22, 10:09 pm

On Oct 21, 3:10 am, "Andr=E9 Gillibert"
<tabkanDELETETHIS...@yahodeletethato.fr> wrote:

[color=darkred]
[color=darkred]
> 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

Sponsored Links