This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: partly bracketed initializer ?
- To: bob at werken dot com
- Subject: Re: partly bracketed initializer ?
- From: "Martin v. Loewis" <martin at mira dot isdn dot cs dot tu-berlin dot de>
- Date: Sat, 20 Feb 1999 11:21:07 +0100
- CC: egcs at egcs dot cygnus dot com
- References: <Pine.LNX.3.96.990220032655.7438P-100000@exeter.exeter.org>
> What is a partly bracketed initializer warning?
The allocator template uses a pthread_mutex_t object
__node_allocator_lock. On 2.5.1, this is defined as
typedef struct _pthread_mutex {
struct {
uint8_t pthread_mutex_flag[4];
uint32_t pthread_mutex_type;
} pthread_mutex_flags;
union {
struct {
uint8_t pthread_mutex_pad[8];
} pthread_mutex_lock64;
uint64_t pthread_mutex_owner64;
} pthread_mutex_lock;
uint64_t pthread_mutex_data;
} pthread_mutex_t;
Sun uses the construct {0,0,0} to initialize such a thing; this
doesn't reflect the data structure very well. The correct
initialization is {{{0,0,0,0}, 0}, {pthread_mutex_owner64:0}, 0}
> Should I be concerned?
Somewhat. For the current initialization, I get (in a reduced example)
b:
.byte 0
.byte 0
.byte 0
.skip 1
.skip 4
.skip 16
whereas for the complete initialization, I get
b:
.byte 0
.byte 0
.byte 0
.byte 0
.uaword 0
.uaword 0
.uaword 0
.uaword 0
.uaword 0
So the Sun code only partially initializes the object.
Since we are talking about a static member, it is zero-initialized
anyway, and therefore it happens to work. I'm not sure about the
constraints on mutex_t objects - if you can make them automatic
variables, you might run into problems.
> Is the a -Wno-bracketed-initializer to turn them off if I'm
> not concerned?
Yes, it's called -Wno-missing-braces.
Regards,
Martin