Gettext macros (and a couple other ones)

[Alessio Vanni]

Hello,

there is a problem regarding the usage of gettext in header files,
specifically in `gnunet_common.h'.

In that file, a number of macros expand to a call to `GNUNET_log' with
its template string wrapped inside a call to `_', which is the common
gettext alias.

Within GNUnet itself this doesn't pose any particular issue, but once
the file is included in a third-party application that does not include
"platform.h" things break down.

The issue arises from the fact that applications don't always define `_'
to be anything at all, unless gettext is explicitly used for something
within the application itself.

The workaround currently is to begin each file with a directive to
include `gnunet_util_lib.h' like this:

// This in case Autoconf or equivalent is used.
#include "config.h"

#include <gnunet/gettext.h>
#include <gnunet_util_lib.h>
// Other includes here...

#define _(Str) (Str)

This is unnecessary boilerplate: because gettext-ized strings are used
in macros, there's no reason to keep `gettext.h' outside the util
header, to begin with.

Having to explicitly define `_' is the major issue though.

First, because the application shouldn't be concerned with the internals
of a library's macros. Having to define a possibly useless (for the
actual application) macro just because it would fail to compile
otherwise is a bug in the library.

Second, and most importantly, because that alias is commonly associated
with the "application domain" version of gettext, i.e. strings inside
that macro will be translated according to the PO files provided by the
application and not by the library.

This means that once the application is being executed, gettext will try
to search the application's PO files for the e.g. the string

"Assertion failed at %s:%d. Aborting.\n",

failing because that string is defined in a header which gettext doesn't
know about, thus always displaying the original string and defeating the
purpose of using gettext at all.

Inside GNUnet, `_' is actually defined to be "dgettext(PACKAGE, Str)"
inside `platform.h', but as said before outside GNUnet itself it's not
always desirable to include it, especially so if Autoconf is used as
`platform.h' implicitly includes `gnunet_config.h', which conflicts with
an application's `config.h' header.

For this problem the solution is simple: just change any call to `_'
with an explicit call to `dgettext' and give it the appropriate domain,
but this actually creates a new issue.

Currently, GNUnet's gettext domain is set inside the
`GNUNET_OS_ProjectData' structure defined in `gnunet_os_installation.c'
and it's set to the macro "PACKAGE". To make sure both GNUnet's
internals and the macros in the util header use the same domain, the
dgettext calls ought to also use PACKAGE as their domain arguments.

The issue here is that PACKAGE can't be used directly inside the header:
any application defining the PACKAGE macro before including the util
header (trivially anything using Autoconf) would effectively override
the specified domain from GNUnet's to the application's own, going back
to the current behaviour documented above.

While I was investigating this issue I discovered that there is at least
one other macro where an Autoconf macro can be overridden, giving an
inappropriate value.

Again inside the util header there is the macro "GNUNET_AGPL_URL", which
is currently defined as:

#define GNUNET_AGPL_URL "https://gnunet.org/git/gnunet.git#"; PACKAGE_VERSION

Inside GNUnet this correctly gives
"https://gnunet.org/git/gnunet.git#0.15.2"; (or whatever the current
version is when expanded), but if used within an application with e.g. a
version number of "13.0.1" it will generate
"https://gnunet.org/git/gnunet.git#13.0.1"; which is obviously incorrect
as of today.

I can think of a couple of ways to fix these issues, for example by
having a separate header file for this kind of macros, which is expanded
by Autoconf at configure time (i.e. a ".h.in" generating a ".h") and
thus the values can't be overridden, but before progressing I'd like to
ask for opinions, in case changing how these macros are handled ends up
touching things I wasn't aware of.

Hopefully things can be changed without too many consequences, as it's
otherwise a fairly easy issue to tackle and fix.

Thanks,
A.V.

P.S.: Apologies for the long e-mail for what in the end is a simple
issue, but I wanted to explain in details to avoid (as much as possible)
misunderstandings. :)

P.P.S: Is the GNUNET_AGPL_URL value correct? Currently it redirects to
the homepage of git.gnunet.org, but I don't know if that's what it
should point to.