• MarsRook <MarsRook_member pathlink.com> Jan 12 2005
• "Jackson A. Marshall" <nospam nospam.org> Jan 12 2005
• MarsRook <MarsRook_member pathlink.com> Jan 13 2005
• "Jackson A. Marshall" <nospam nospam.org> Jan 13 2005
• MarsRook <MarsRook_member pathlink.com> Jan 13 2005
• "Walter" <newshound digitalmars.com> Feb 16 2005

typedef union {
uint32 all;
struct { uint32 a:7, b:9, c:6, d:10; };
} ut;

ut u;

u.a=0; u.b=0; u.c=0; u.d=0;  // initializing all 32 bits
dosomething(u);

/*
The compiler will issue a warning that u is not initialized before its use.
But it will issue the warning only if the optimizer is on.
*/

"MarsRook" <MarsRook_member pathlink.com> wrote in message
news:cs3app$1q0u$1 digitaldaemon.com...
 typedef union {
 uint32 all;
 struct { uint32 a:7, b:9, c:6, d:10; };
 } ut;

 ut u;


ut u = { 0 };

 u.a=0; u.b=0; u.c=0; u.d=0;  // initializing all 32 bits
 dosomething(u);

 /*
 The compiler will issue a warning that u is not initialized before its use.
 But it will issue the warning only if the optimizer is on.
 */

Thanks for your info.

But this time I did not intend to get
assistance, I rather wanted to post
info about the observed dmc behaviour.

There are actually several ways to keep
dmc quiet during compilation. It just
does not make sense to me initializing
the union first and then assigning values
to the individual bitfields.

------------

In article <cs3baj$1qk4$1 digitaldaemon.com>, Jackson A. Marshall says...
"MarsRook" <MarsRook_member pathlink.com> wrote in message
news:cs3app$1q0u$1 digitaldaemon.com...
 typedef union {
 uint32 all;
 struct { uint32 a:7, b:9, c:6, d:10; };
 } ut;

 ut u;


ut u = { 0 };

 u.a=0; u.b=0; u.c=0; u.d=0;  // initializing all 32 bits
 dosomething(u);

 /*
 The compiler will issue a warning that u is not initialized before its use.
 But it will issue the warning only if the optimizer is on.
 */

"MarsRook" <MarsRook_member pathlink.com> wrote in message
news:cs5v4p$2hm6$1 digitaldaemon.com...
 In article <cs3baj$1qk4$1 digitaldaemon.com>, Jackson A. Marshall says...
"MarsRook" <MarsRook_member pathlink.com> wrote in message
news:cs3app$1q0u$1 digitaldaemon.com...
 typedef union {
 uint32 all;
 struct { uint32 a:7, b:9, c:6, d:10; };
 } ut;

 ut u;


ut u = { 0 };

 u.a=0; u.b=0; u.c=0; u.d=0;  // initializing all 32 bits
 dosomething(u);

 /*
 The compiler will issue a warning that u is not initialized before its use.
 But it will issue the warning only if the optimizer is on.
 */





 Thanks for your info.

 But this time I did not intend to get
 assistance, I rather wanted to post
 info about the observed dmc behaviour.

 There are actually several ways to keep
 dmc quiet during compilation. It just
 does not make sense to me initializing
 the union first and then assigning values
 to the individual bitfields.


It's always good programming practice to initialise variables,
and not doing so can hardly be called a DM bug, minor or
otherwise.

jam


A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

In article <cs641i$2nae$1 digitaldaemon.com>, Jackson A. Marshall says...


It's always good programming practice to initialise variables,
and not doing so can hardly be called a DM bug, minor or
otherwise.



I guess if you didn't get it so far, you won't get it anyway.
Nevertheless, I can spare some more minutes:

I am talking about dmc complaining even if ALL bitfields are
individually INITIALIZED. This does not happen in the latest
releases of:  gcc, lcc-W32, OpenWatcom and VC++.
(Even dmc itself does not issue a warning, if it is not set
to optimize.)

I'll still call this "minor bug" unless I find someone who
can lecture me how to express this phenomenon otherwise.

You'd probably call it "compiler feature" if it forces you
to double-initialize bitfield unions in optimizing mode.

"MarsRook" <MarsRook_member pathlink.com> wrote in message
news:cs7ldt$19ad$1 digitaldaemon.com...
 I'll still call this "minor bug" unless I find someone who
 can lecture me how to express this phenomenon otherwise.


You're right, it is a bug. Thanks for reporting it.