Volunteer needed!
In a gnulib testdir of module 'mtx'
./gnulib-tool --create-testdir --dir=../testdir --single-configure mtx
on FreeBSD 12.0, when configured with --enable-threads=isoc, the test
'test-mtx' hangs and only terminates by timeout. The test function that
hangs is test_once.
Without
> * tests/test-nl_langinfo-mt.c: New file.
More multithread-safety tests are likely to come. Since they will all
have a runtime of a couple of seconds each, it's useful to make these
tests easily recognizable, through some naming convention. Let me
use '-mt' to denote such a test.
2019-12-
> 2019-12-18 Bruno Haible
>
> hard-locale: Add test.
> * tests/test-hard-locale.c: New file.
> * tests/locale.c: New file.
> * modules/hard-locale-tests: New file.
The weekly continuous integration build [1] detected that this causes a
testdir build failure. Namely, the
Hi Daniel,
> > Thanks. From this, I think we can equate the following vendor names
> > with GNU canonical names:
>
> Is there a good test to ensure that the conversions are as expected? I
> wouldn't put it past IBM to use a strange variant of some of these otherwise-
> familiar encodings...
Oh,
Hi Daniel,
> > Can you please do a fresh start on this?
> > - Create a testdir for module 'pthread-rwlock'.
> > - Build it with -D_UNIX95_THREADS -D_XOPEN_SOURCE=600.
>
> That gives me the same compile error as a full build:
>
> source='/tmp/testdir/gltests/test-pthread.c' object='test-pthre
A year ago, I committed this:
2018-12-21 Bruno Haible
memcmp: Mention the clang bug.
* tests/test-memcmp.c: Add comment about a known test failure.
* doc/posix-functions/memcmp.texi: Mention the clang bug.
But a comment does not stop the test from failing :) So, here's to
On Fri, 2019 Dec 20 03:19-05:00, Bruno Haible wrote:
>
> Thanks. From this, I think we can equate the following vendor names
> with GNU canonical names:
Is there a good test to ensure that the conversions are as expected? I
wouldn't put it past IBM to use a strange variant of some of these otherw
Paul Eggert wrote:
> On 12/16/19 2:12 AM, arn...@skeeve.com wrote:
> > What about
> >
> > typedef ptrdiff_t dfa_size_t
>
> That declaration would imply that the type is specific to DFAs. However, the
> type is used (with exactly the same meaning) in a lot of other places. This is
> why I use
Hi Daniel,
> I've attached a file with the output of "iconv -l". The names appear
> consistent with what's in iconv_open-aix.gperf.
Thanks. From this, I think we can equate the following vendor names with
GNU canonical names:
Vendor name Canonical name References
00367ASCII,
