GNU 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: |
Guido Flohr <gflohr> |
Tue 12 May 2020 03:07:33 PM UTC, comment #1:
|
Bruno Haible <haible> |
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):
|
Guido Flohr <gflohr> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
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 | Category | None | Programmer tools | |
Summary | xgettext does not escape special characters in comments | xgettext does not reject bogus file names when emitting file references |
Powered by Savane 3.13-f8d8.
Corresponding source code
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.