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.
