Hello,
When trying to compile an older gettext tarball with libunistring
0.9.5-alpha3 (with an update to Unicode 7.0.0), I encountered a test
failure caused by a data mismatch:
FAIL: uniname/test-uninames.sh
==
\u037F name lookup returned wrong name: GREEK CAPIT
On 27/11/14 08:47, Daiki Ueno wrote:
> Hello,
>
> When trying to compile an older gettext tarball with libunistring
> 0.9.5-alpha3 (with an update to Unicode 7.0.0), I encountered a test
> failure caused by a data mismatch:
>
> FAIL: uniname/test-uninames.sh
> ==
>
Pádraig Brady writes:
>> This prefers system's libunistring to the corresponding Gnulib module.
>> I think Gnulib tests should rather prefer Gnulib modules. Does anyone
>> know what's the rationale behind this?
>
> The tests generally test the combination of system and gnulib bits.
> Ideally the
* m4/printf.m4 (gl_PRINTF_INFINITE_LONG_DOUBLE): Add missing bracket.
---
ChangeLog| 5 +
m4/printf.m4 | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/ChangeLog b/ChangeLog
index e051495..cd7d8ee 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2014-11-27 Pádr
I noticed that vfprintf() was replaced on my glibc-2.20 system,
which is surprising and a lot of code to be duplicating.
This gets pulled in because:
$ grep gl_cv_func_printf.*=no config.log
gl_cv_func_printf_infinite_long_double=no
$ grep -A5 "checking.*infinite 'long double' arguments" conf
On Thu, Nov 27, 2014 at 3:23 AM, Pádraig Brady wrote:
> * m4/printf.m4 (gl_PRINTF_INFINITE_LONG_DOUBLE): Add missing bracket.
...
> diff --git a/m4/printf.m4 b/m4/printf.m4
...
> - ((unsigned int) (manthi) << 16) | (unsigned int) (mantlo) >> 16),\
> + ((unsigned int) (manthi) << 16
Pádraig Brady wrote:
Are these checks backed up by corresponding replacement code?
Are these checks correct?
Why has glibc not been updated in the 7 years since the checks were added?
As I recall, this comes from an old dispute about what glibc should do when
asked to print floating-p
