c++ - Minor Bug
- MarsRook (11/11) Jan 12 2005 typedef union {
- Jackson A. Marshall (2/13) Jan 12 2005
- MarsRook (11/31) Jan 13 2005 Thanks for your info.
- Jackson A. Marshall (9/43) Jan 13 2005 It's always good programming practice to initialise variables,
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. */
Jan 12 2005
"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. */
Jan 12 2005
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. */
Jan 13 2005
"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...It's always good programming practice to initialise variables, and not doing so can hardly be called a DM bug, minor or otherwise."MarsRook" <MarsRook_member pathlink.com> wrote in message news:cs3app$1q0u$1 digitaldaemon.com...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.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. */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?
Jan 13 2005
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.
Jan 13 2005
"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.
Feb 16 2005