bugGNU gettext - Bugs: bug #43970, Incorrect "warning:...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #43970: Incorrect "warning: unterminated string literal" for some C++11 raw strings

Submitted by:  Vaclav Slavik <vslavik>
Submitted on:  Sat 10 Jan 2015 02:27:48 PM UTC  
 
Category: CSeverity: 3 - Normal
Item Group: NoneStatus: Fixed
Privacy: PublicAssigned to: Daiki Ueno <ueno>
Open/Closed: Closed

Tue 13 Jan 2015 03:17:03 AM UTC, comment #5:

Thanks, that sounds a reasonable solution (given that the C standard is unlikely to incorporate raw string literals in near future).

I've pushed a couple of patches along these lines:
http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=4dfe1c4609a5c600112cd83a4d3af5d4e4d402c7
http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=383b5ba48b20bc6583ee63f13741dd84e96c5002

Daiki Ueno <ueno>
Project AdministratorIn charge of this item.
Mon 12 Jan 2015 10:29:46 AM UTC, comment #4:

I see, this didn't occur to me (nor the fact that C++11 compiler won't compile this until now). Wouldn't it be better, then, to (if necessary) start making a distinction between C and C++ modes, instead of introducing a new C++11 one? IMHO the example you gave is quite artificial and very unlikely to occur in practice, but I get your point. It is even less likely to occur in C++, though, because of the C++ culture that really frowns upon such macro uses. Plus C++ compilers will eventually switch to having C++11/4/7 as the default (some already did, although not gcc) and such code would have to be updated anyway, making the chance of it occurring ever smaller.

The advantage of that would be that xgettext already differentiates between C and C++ in its user interface (although not in the implementation, I think). And it wouldn't be something that would have to be reevaluated in a few years once legacy C++98 becomes, well, legacy for real.

Vaclav Slavik <vslavik>
Sun 11 Jan 2015 10:43:28 PM UTC, comment #3:

Consider the following code:

This is a valid pre-11 code which passes a string "fooaaa(あ" to gettext, but invalid as C++11. If xgettext treated the code as C++11, it couldn't detect the error until EOF is read.

> Wouldn't it be better to loosen the warning instead? As far as I can tell, it isn't causing any harm in this case - gettext-wrapped strings following after such raw strings are still recognized by xgettext correctly, so it doesn't seem to break the parser?


Yes, if that is possible, it would be a desired behavior.

Daiki Ueno <ueno>
Project AdministratorIn charge of this item.
Sun 11 Jan 2015 05:39:46 PM UTC, comment #2:

> (e.g. LR is defined as an ordinary C identifier).


I'm not sure I follow - how could that possibly be valid C or pre-11 C++ code? I think the syntax is intentionally such that it cannot be misinterpreted as valid C.

> Perhaps we should add a new language tag, like xgettext -L C++11, to toggle this feature.


IMNSHO that would be a mistake, for two reasons:

1) C++11 is (modern) C++ and there will be more and more of it (and C++14 and C++17...). It doesn't make much sense to treat the current thing specially and worse, make it non-default.

2) It would break extension-based detection of the language and make using xgettext with the current/default version of C++ harder. That includes tools on top of xgettext (e.g., selfishly, Poedit) that would have no reasonable way of detecting C++11 use and would have to require user configuration for things that should "just work".

Wouldn't it be better to loosen the warning instead? As far as I can tell, it isn't causing any harm in this case - gettext-wrapped strings following after such raw strings are still recognized by xgettext correctly, so it doesn't seem to break the parser?

Vaclav Slavik <vslavik>
Sun 11 Jan 2015 08:31:20 AM UTC, comment #1:

Thanks for the report. Yes, there are a couple of problems in the raw string scanner: determining the end of a raw string, and handling escape sequences differently from ordinary strings.

I'm attaching a patch to those, but I'm concerned that this change might introduce an incompatibility with C code based on the older standard (e.g. LR is defined as an ordinary C identifier). Perhaps we should add a new language tag, like xgettext -L C++11, to toggle this feature.

(file #32804)

Daiki Ueno <ueno>
Project AdministratorIn charge of this item.
Sat 10 Jan 2015 02:27:48 PM UTC, original submission:

I'm filing this bug even though there's #43726 (closed as duplicate), because I can't figure out how to reopen the bug.

I tested this with the latest xgettext 0.19.4; this is not an issue of missing C++11 support, but seems to be a problem with handling of quote characters contained in a raw string. Full reproducible example:

$ cat >x.cpp
LR"(\(\s['"]([^'"]+)['"]\s[,)])";
$ xgettext -o- x.cpp
x.cpp:0: warning: unterminated string literal
$

Vaclav Slavik <vslavik>

 

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by haible (Updated the item)
  • -unavailable- added by ueno (Updated the item)
  • -unavailable- added by vslavik (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 27 Nov 2016 11:57:10 AM UTChaibleCategoryNone=>C
    Tue 13 Jan 2015 03:17:03 AM UTCuenoStatusConfirmed=>Fixed
      Open/ClosedOpen=>Closed
    Sun 11 Jan 2015 08:31:20 AM UTCuenoAttached File-=>Added 0001-c-Make-C-11-raw-string-recognition-stricter.patch, #32804
      StatusNone=>Confirmed
      Assigned toNone=>ueno

    Back to the top


    Powered by Savane 3.1-cleanup1