While testing a grep snapshot on OpenBSD 6.3, I see a test failure of
test-localename. The cause is that in OpenBSD >= 6.2, the locale_t
type and uselocale() etc. are now available, but with a terribly dumbed-
down implementation that makes it impossible to use these per-thread
locales for anything
Kevin Cernekee submitted this on 2015-02-12:
> diff --git a/tests/test-duplocale.c b/tests/test-duplocale.c
> index f5da517bf3f8..18913f1b8b7d 100644
> --- a/tests/test-duplocale.c
> +++ b/tests/test-duplocale.c
> @@ -20,7 +20,7 @@
>
> #include
>
> -#if HAVE_DUPLOCALE
> +#if HAVE_DUPLOCALE &&
FreeBSD also has uselocale() et al, since version 9.1, see
https://www.freebsd.org/releases/9.1R/relnotes.html
https://svnweb.freebsd.org/base?view=revision&revision=235785
https://svnweb.freebsd.org/base?view=revision&revision=227753
And AIX 7 as well.
2018-12-16 Bruno Haible
locale
On Sat, Dec 15, 2018 at 3:50 PM Bruno Haible wrote:
> While testing a grep snapshot on NetBSD 8, I see that the gnulib test
> 'test-openat-safer' fails:
>
> FAIL: test-openat-safer
> ===
>
> ../../gnulib-tests/test-openat-safer.c:101: assertion 'STDERR_FILENO < fd'
> failed
>
While testing a grep snapshot on NetBSD 8, I see that the gnulib test
'test-openat-safer' fails:
FAIL: test-openat-safer
===
../../gnulib-tests/test-openat-safer.c:101: assertion 'STDERR_FILENO < fd'
failed
FAIL test-openat-safer (exit status: 134)
The reason is that the te
On Sat, Dec 15, 2018 at 2:08 PM Bruno Haible wrote:
> Hi Jim,
> > > I guess the fix should be to detect the glibc bug in m4/regex.m4 ?
> >
> > Exactly. That's what I'm doing now.
> > I'm expecting to insert something like this, probably reusing the
> > result value of "64":
> >
> > /*
On NetBSD 8 and other platforms, while testing a grep snapshot, I see this
error message:
test: yes: unexpected operator
This patch fixes it.
2018-12-15 Bruno Haible
localename: Fix use of uninitialized shell variable.
* m4/intl-thread-locale.m4 (gt_INTL_THREAD_LOCALE_NAME)
Hi Jim,
> > I guess the fix should be to detect the glibc bug in m4/regex.m4 ?
>
> Exactly. That's what I'm doing now.
> I'm expecting to insert something like this, probably reusing the
> result value of "64":
>
> /* Matching with the compiled form of this regexp would
> provoke
>
On Alpine Linux 3.7.0 (x86_64), the gnulib-tests of a 'grep' snapshot fail:
FAIL: dfa-match.sh
The problem is here:
+ timeout 10 dfa-match-aux a bb
bb 1
timeout: can't execute '10': No such file or directory
+ fail=1
This distro has a 'timeout' program, and 'timeout --help' reports (on stderr!)
FYI: I've just pushed this:
>From 95cd86dd7aa4425037b9c710f88fd59e38601ff1 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sat, 15 Dec 2018 10:09:35 -0800
Subject: [PATCH] dfa: avoid new warnings from gcc
These would prevent building with -Werror and a Dec snapshot of gcc.
* lib/dfa.c (dfaanal
The "symlink ownership not supported" condition is expected to be
indicated by EOPNOTSUPP, as opposed to the "no support for ownership",
which is indicated by ENOSYS.
The latter condition is checked for earlier in this test on a
directory (rather than on a symlink). And if ENOSYS is raised for a
s
I can think of two ways to think about the purpose of this test:
1. distinguish stack overflow from an access to an invalid address
("programm error")
2. distinguish stack overflow from other cases when SIGSEGV is sent
Under view 2, then the access to an invalid address is just an
implementation
Hello,
On 2018-12-14 3:36 p.m., Paul Eggert wrote:
This does not ring a bell with me. Presumably the "# define __random_r
random_r" business in lib/random_r.c and lib/stdlib.in.h also need to be
done for random and srandom in lib/random.c and lib/stdlib.in.h?
Thanks for the hint.
The attache
13 matches
Mail list logo
