Re: [Tinycc-devel] [BUG] Nested array/struct/union initialization problem

[Rob Landley]

On Tuesday 25 September 2007 11:37:01 am Marc Andre Tanner wrote:
> Hi,
>
> Okay this is currently way too complicated for me to solve on my own.
> The follwoing code sniped demonstrates the issue. Tcc exits with:
>
>     bug.c:13: identifier expected
>
> The call to expect comes from within unary () at tcc.c:6587 where t = '.'

Um, yes.  Evil.

> struct format_option {
>          union {
>                  const char * fo_str ;
>                  int fo_int ;
>                  int fo_time ;
>          } ;
>          unsigned int empty : 1 ;
>          enum { FO_STR , FO_INT , FO_TIME } type ;
>          char ch ;
> } ;
>
> static struct format_option track_fopts [ 11 ] = {
>          { { . fo_str = ( ( void * ) 0 ) } , 0 , FO_STR , 'a' } ,
>          { { . fo_str = ( ( void * ) 0 ) } , 0 , FO_STR , 'l' } ,
>          { { . fo_int = 0 } , 0 , FO_INT , 'D' } ,
>          { { . fo_int = 0 } , 0 , FO_INT , 'n' } ,
>          { { . fo_str = ( ( void * ) 0 ) } , 0 , FO_STR , 't' } ,
>          { { . fo_str = ( ( void * ) 0 ) } , 0 , FO_STR , 'y' } ,
>          { { . fo_str = ( ( void * ) 0 ) } , 0 , FO_STR , 'g' } ,
>          { { . fo_time = 0 } , 0 , FO_TIME , 'd' } ,
>          { { . fo_str = ( ( void * ) 0 ) } , 0 , FO_STR , 'f' } ,
>          { { . fo_str = ( ( void * ) 0 ) } , 0 , FO_STR , 'F' } ,
>          { { . fo_str = ( ( void * ) 0 ) } , 0 , 0 , 0 }
> } ;
>
> Would be great if someone could take a look at it.

That would probably be me. :)

I currently have about 5 tcc issues backlogged (including your ' in #warning 
thing), and didn't give tcc any time this weekend because I was backlogged on 
day job stuff (linux-kernel documentation, http://kernel.org/doc/master.html 
is finally starting to shape up and http://kernel.org/doc/ols/2004 is at 
least no longer _blank_, if not as detailed as the first half of 
http://kernel.org/doc/ols/2002 ...)

Anyway, the first thing I'd do is try to pare the test case down to something 
smaller.  The bug thingy is implying it's dying on the _first_ of the 11 
assignments, so the others could theoretically go away and still reproduce 
the bug.

I'm currently looking at unary() for one of the other issues (the segfault 
when generating code in a global before the first function in a file, due to 
const_wanted and nocode_wanted both being ignored and code being generated 
anyway, and if you trace down from expr_lor_const() and see how _many_ 
different places code generation is called from, it's not surprising that a 
lot aren't guarded.

I suspect the easy way to fix this is for nocode_wanted to just swap 
cur_text_section to point to a dummy output section, and then either discard 
the result or check if anything was generated and barf if it was illegal for 
it to do so.  Then all the nocode_wanted tests can go away.  Might waste a 
little ram at runtime, but it does that anyway, and something like that gives 
us the possibility of doing dead code elimination for if(0) intelligently yet 
revert to outputting code after the fact if there's a jump target label in 
there... :)

> Thanks,
> Marc

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.