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

Submitter:  Vaclav Slavik <vslavik>
Submitted:  Sat 10 Jan 2015 02:27:48 PM UTC
   
 
Category:  C Severity:  3 - Normal
Item Group:  None Status:  Fix Released
Privacy:  Public Assigned to:  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>
Group administrator
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:


#include <stdio.h>
#define R "foo"
void foo (void) { printf ("%s\n", gettext (R"aaa(\u3042")); }
int main (void) { foo (); return 0; }


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>
Group administrator
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>
Group administrator
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>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-01-04 haible StatusFixed Fix Released
    2016-11-27 haible CategoryNone C
    2015-01-13 ueno StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2015-01-11 ueno Attached 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.13-caa5.
    Corresponding source code