bug-gettext
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug-gettext] [bug #45048] Variable check in po.m4 should be improved to


From: anonymous
Subject: [bug-gettext] [bug #45048] Variable check in po.m4 should be improved to clarify intent
Date: Thu, 07 May 2015 19:59:01 +0000
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36

URL:
  <http://savannah.gnu.org/bugs/?45048>

                 Summary: Variable check in po.m4 should be improved to
clarify intent
                 Project: GNU gettext
            Submitted by: None
            Submitted on: Thu 07 May 2015 07:58:59 PM UTC
                Category: None
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

The test of LINGUAS in po.m4 (code that is transferred to
configure/config.status) appears to allow for errors:

LINGUAS="${LINGUAS-%UNSET%}"

This check can have 3 outcomes, but I don't think that is the intent. From
what I can determine, the value of LINGUAS after this statement is supposed to
be either (1) what was LINGUAS before, or (2) the value "%UNSET%". But the
above code allows for a resulting value of null if the variable was set but
empty.

In the p11-kit (0.23.1) this problem appears, and current levels of the build
tools expose a failure when trying to build the language support files. The
p11-kit code erroneously sets LINGUAS='' in its configure.ac, which causes a
problem here. Right or wrong, this check can accommodate this mistake with a
small change.

The correct syntax should be:

LINGUAS="${LINGUAS:-%UNSET%}"

(Note the colon before the hyphen) which will ensure that the result is either
the previous value or %UNSET%. Subsequent checks for %UNSET% will therefore
succeed, and the variable will never be null (empty) after this point.





    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?45048>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]