Re: Gettext macros (and a couple other ones)

[Christian Grothoff]

On 8/25/21 9:42 PM, Alessio Vanni wrote:
> 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.

Good point, but that's a specific issue with that macro, which I agree
should not use "_" but dgettext(). I've fixed this (and a few related)
instance(s) in Git master just now.

> 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.

There is a much simpler (and IMO proper) solution: GNUNET_OS_ProjectData
should really just use "gnunet" and not PACKAGE.

> 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

Oh, that should at least be updated to git.gnunet.org, fixing as well ;-).

> 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.

I think that would likely be the best fix for the PACKAGE_VERSION issue.
 We _could_ use this also for the PACKAGE issue you raised, but here I'm
fine with just hard-coding "gnunet" as a quick fix.

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

I also do not currently see any unintended consequences of what you
describe.

> 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. :)

Thanks for the very clear report ;-).

> 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.

The idea was to point to the tag. I have fixed that in Git as well.

-Christian

signature.asc
Description: OpenPGP digital signature