[asterisk-dev] gcc bug with zero-sized arrays and struct initializers.

[Luigi Rizzo]

On Tue, Oct 30, 2007 at 12:51:56PM +0000, Tony Mountifield wrote:
> In article <20071030032741.A86261 at xorpc.icir.org>,
> Luigi Rizzo <rizzo at icir.org> wrote:
> > Some time ago i hit a problem with chan_iax which I eventually tracked
> > down as related to the problem below - namely a compiler bug with
> > struct initializers after zero-sized arrays.
> > 
> > This was with gcc 2.95 - now, i know this is obsolete, but the bug is
> > very subtle and it is unclear that other compiler versions are not
> > affected.
> > 
> > I am mentioning it in this list because this construct is used widely
> > in asterisk (string fields have a zero-sized array used as a marker),
> > and it would be good to check whether other compiler versions handle
> > this correctly.
> > 
> > 	cheers
> > 	luigi
> > 
> > 
> > /* This code shows a problem with gcc 2.95, 0-sized arrays and initializers:
> >  * Initializing a field right after a 0-sized array fails (the compiler emits
> >  * no code).
> >  */
> > 
> > struct foo {
> >         char *pre[0];
> >         int a;
> > };
> 
> Why would you want an element AFTER a zero-sized array? In the above
> example, pre[0] would occupy the same storage as a.
> 
> Surely the zero-sized array is supposed to be the final item in the struct,
> so that the struct defines the fixed part and the array then identifies the
> beginning of the variable-length part.

asterisk's stringfields

http://svn.digium.com/view/asterisk/trunk/include/asterisk/stringfields.h?view=log

are defined using macros, and the wrapper code (macro
AST_DECLARE_STRING_FIELDS() ) places a zero-size array as a marker
before the first element, and a zero-size array as a marker after
the last element.  Macros then do pointer arithmetics using the
start marker.

Now, surely there are alternative and more standard-compliant ways
to do it - e.g. replace the current markers with real fields,
splitting struct ast_string_field_mgr and placing at least one field
before and one field after the variable part.

In fact, i think we should make this change to the header just to
avoid this kind of problems with compilers..

On the other hand, you wouldn't expect the compiler to fail so badly.

	cheers
	luigi