bugGNU gettext - Bugs: bug #58356, xgettext does not reject bogus...

 
 

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

bug #58356: xgettext does not reject bogus file names when emitting file references

Submitter:  Guido Flohr <gflohr>
Submitted:  Tue 12 May 2020 10:53:19 AM UTC
   
 
Category:  Programmer tools Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open

Tue 12 May 2020 03:16:18 PM UTC, comment #2: 


> Similarly, commas should be escaped, so that a source file "foo.c:42, bar.c" would not result in two references.


My bad ... references are separated by spaces not by commas.

But that means that filenames containing spaces should be rejected as well. Strictly speaking, it would be sufficient to reject filenames that match the regex /:[0-9]+ ./ but probably most PO editors will simply split at a space and that guard would not be sufficient for them.

Guido Flohr <gflohr>
Group Member
Tue 12 May 2020 03:07:33 PM UTC, comment #1: 


> It is, of course, not a valuable feature to be able to process filenames with embedded commas or newlines.


True. The cost of such a feature - namely, that PO editors that want to show the files need to unescape the file names - would not be worth the benefit. It would complicate the PO file format specification for too little benefit.

> A simple solution would be to just throw a fatal error for such cases.


Agreed.

Bruno Haible <haible>
Group administrator
Tue 12 May 2020 10:53:19 AM UTC, original submission:  

I have a C source file "two\nlines.c" (with an embedded newline character in the name):

$ cat 'two
lines.c'
gettext("Hello, world!\n");
$ xgettext 'two
lines.c'
$ msgfmt messages.po
messages.po: warning: Charset "CHARSET" is not a portable encoding name.
                      Message conversion to user's charset might not work.
messages.po:21: keyword "lines" unknown
messages.po:21:6: syntax error
msgfmt: found 2 fatal errors
$ cat messages.po
# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2020-05-12 11:52+0300\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"Language: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=CHARSET\n"
"Content-Transfer-Encoding: 8bit\n"

#: /tmp/two
lines.c:1
msgid "Hello, world!\n"
msgstr ""

Similarly, commas should be escaped, so that a source file "foo.c:42, bar.c" would not result in two references.

It is, of course, not a valuable feature to be able to process filenames with embedded commas or newlines. But the current state is that xgettext produces a file without errors or warnings that msgfmt cannot parse.

A simple solution would be to just throw a fatal error for such cases.

Guido Flohr <gflohr>
Group Member

 

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

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by haible (Posted a comment)
  • -email is unavailable- added by gflohr (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 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-05-12 haible CategoryNone Programmer tools
        Summaryxgettext does not escape special characters in comments xgettext does not reject bogus file names when emitting file references

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code