[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bison 2.4 breaks libIDL 0.8.11 build
From: |
Joel E. Denny |
Subject: |
Re: bison 2.4 breaks libIDL 0.8.11 build |
Date: |
Tue, 4 Nov 2008 14:40:00 -0500 (EST) |
On Tue, 4 Nov 2008, Juergen Daubert wrote:
> > > ./parser.y:610.9-10: $$ for the midrule at $6 of `struct_type' has no
> > > declared type
> > > ./parser.y:627.9-10: $$ for the midrule at $10 of `union_type' has no
> > > declared type
These errors are legitimate.
> struct_type: z_props TOK_STRUCT
> { $<str>$ = "struct"; }
> z_new_scope_catch '{' {
> g_hash_table_insert (__IDL_structunion_ht, $4, $4);
> 610: $$ = IDL_type_struct_new ($4, NULL);
It is a bug that Bison 2.3 accepts this line. The user failed to specify
the semantic type for the mid-rule value (referenced by $$ here but $6 in
later actions). Bison 2.3 accidentally uses the semantic type from the
LHS (which would be referenced by $$ if this were not a mid-rule). The
user is lucky that this just happens to be the right semantic type.
Bison 2.3a and later correctly spot this as a user error and fail because
they realize there's no logical way to proceed. The line should be
rewritten as:
$<tree>$ = IDL_type_struct_new ($4, NULL);
> } member_list
> '}' pop_scope {
> g_hash_table_remove (__IDL_structunion_ht, $4);
> $$ = $<tree>6;
This line correctly specifies the type of that same mid-rule value.
> __IDL_assign_up_node ($$, $7);
> IDL_TYPE_STRUCT ($$).member_list = $7;
> assign_props (IDL_TYPE_STRUCT ($$).ident, $1);
> }
> ;
>
> union_type: z_props TOK_UNION
> { $<str>$ = "union"; }
> z_new_scope_catch TOK_SWITCH '('
> switch_type_spec
> ')' '{' {
> g_hash_table_insert (__IDL_structunion_ht, $4, $4);
> 627: $$ = IDL_type_union_new ($4, $7, NULL);
Same problem, different rule.
> } switch_body
> '}' pop_scope {
> g_hash_table_remove (__IDL_structunion_ht, $4);
> $$ = $<tree>10;
But gets it right again.
> __IDL_assign_up_node ($$, $11);
> IDL_TYPE_UNION ($$).switch_body = $11;
> assign_props (IDL_TYPE_UNION ($$).ident, $1);
> }
> ;
I suggest you report this bug to the maintainers of libIDL.