This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
case LOC_CONST_BYTES: - internal_error (__FILE__, __LINE__, - _("gen_var_ref: LOC_CONST_BYTES symbols are not supported")); + internal_error (__FILE__, __LINE__, _("\ +gen_var_ref: LOC_CONST_BYTES symbols are not supported"));
I think this kind of changes confuses cvs for the 'cvs diff -u -p': it might regard the new line +gen_var_ref: LOC_CONST_BYTES symbols are not supported")); as a new starting function line and report a wrong function name... Of course not really for your example here, as the start of the line is the name of the function itself... But I remember having seen wrong function name reported with 'cvs -u -p' due to the use of '_("\' construct which force starting next line without spaces...
Pierre Muller GDB pascal language maintainer
Hmmm... well, we already have tons of similar constructs in the tree.
Yes, I know, and it should of course not retard your commit.
No, I'm concerned about it. If I can see a "nice" solution, I will make changes.
I was just wondering if we could try to avoid those construct in the future, but I am not sure there is a simple solution...
In general, I was wondering if we could use ,_( "gen_var_ref: LOC_CONST_BYTES symbols are not supported")); instead of ,_("\ gen_var_ref: LOC_CONST_BYTES symbols are not supported"));
at least for case that are shorter than 80 - 5(2'"'+2')'+1';') chars? But this might be against GNU coding style.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |