[bug-gettext] Debian Bug#872869: msgfmt: trailing null bytes in header's msgstr

[Santiago Vila]

Dear gettext maintainers:

I applied commit d13f165b8370 to the Debian gettext package, as
suggested by Bruno Haible, and several things happened.

One of them is that now glibc does not build because the gettext tests
still expect the POT-Creation-Date header to be there.
This has been reported here:

https://sourceware.org/bugzilla/show_bug.cgi?id=21508

but this is of course not your fault.

The other interesting thing which happened is explained in the report
below which I have just received.

Apparently the .mo files created now are not very orthodox.

[ Please keep the Cc: lines if you can. Thanks ].

----- Forwarded message from Jakub Wilk <address@hidden> -----

Date: Mon, 21 Aug 2017 22:44:19 +0200
From: Jakub Wilk <address@hidden>
To: address@hidden
Subject: Bug#872869: msgfmt: trailing null bytes in header's msgstr
User-Agent: NeoMutt/20170609 (1.8.3)

Package: gettext
Version: 0.19.8.1-3
Control: affects -1 + i18nspector

The upstream commmit d13f165b8370 updates the header message msgstr, but it
keeps the original msgstr_len ("the number of bytes in msgstr, including the
terminating NUL"). As consequence, in the generated MO file there's a bunch of
null bytes at the end of the msgstr.

I guess this does not matter for gettext-runtime, but it makes i18nspector
(and maybe other strict MO parsers) upset:

  $ msgunfmt /usr/share/locale/pl/LC_MESSAGES/gettext-runtime.mo | msgfmt -
  $ i18nspector messages.mo
  E: messages.mo: invalid-mo-file unexpected null byte in msgstr

[...]