[Bug c++/45431] initializer-string for array of chars is too long: which one?

2010-08-27 Thread redi at gcc dot gnu dot org


--- Comment #1 from redi at gcc dot gnu dot org  2010-08-27 19:10 ---
4.5 and 4.6 give the column number, but of the closing brace, which is no
better


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45431



[Bug c++/45431] initializer-string for array of chars is too long: which one?

2010-08-27 Thread giecrilj at stegny dot 2a dot pl


--- Comment #2 from giecrilj at stegny dot 2a dot pl  2010-08-27 20:58 
---
#9  0x00442a5e in digest_init_r (type=0x7618ac00,
init=0x7617c4c0, nested=1 '\001') at ../../gcc/cp/typeck2.c:785
785 permerror (input_location, initializer-string for
array of chars is too long);
(gdb) l
780   /* In C it is ok to subtract 1 from the length of the
string
781  because it's ok to ignore the terminating null char
that is
782  counted in the length of the constant, but in C++ this
would
783  be invalid.  */
784   if (size  TREE_STRING_LENGTH (init))
785 permerror (input_location, initializer-string for
array of chars is too long);
786 }
787   return init;
788 }
789 }

Symbol input_location is static storage.
The function digest_init_r does not modify it in any way.  It is an oblique
index (601), to be resolved by linemap_lookup in line_table.  If my
investigation is correct, in this particular case it would be
1 + 601  7 == line 5

This particular value is assigned by the function
cp_lexer_set_source_position_from_token, specifically from token-location.

The stack:

#0  cp_lexer_consume_token (lexer=0x7617c340) at ../../gcc/cp/parser.c:662
#1  0x004647f7 in cp_parser_braced_list (parser=0x77e84730,
non_constant_p=0x7fffdb9e ) at ../../gcc/cp/parser.c:14692
#2  0x0046b07c in cp_parser_init_declarator (parser=0x77e84730,
decl_specifiers=0x7fffdbf0, checks=value optimized out, 
function_definition_allowed_p=value optimized out, member_p=0 '\000',
declares_class_or_enum=value optimized out, 
function_definition_p=0x7fffdc5f ) at ../../gcc/cp/parser.c:12893 
The function cp_parser_init_declarator later calls cp_finish_decl
(./../gcc/cp/parser.c:12929), which is where the error is reported.  The error
reporting code incorrectly assumes that the offending line is stored in the
global input_location, which at the moment corresponds to the location of the
closing brace.  However, it seems that after the init tree has been
constructed, the tokens are gone, and so is line number information.

In conclusion, I think the easiest way to fix this problem (and perhaps other
similar ones) would be to add line number information from the original tokens
to the init tree.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45431