i].events & POLLHUP &&
+ recv (pfd[i].fd, data, 64, MSG_PEEK) == -1)
{
if (errno == ESHUTDOWN || errno == ECONNRESET
|| errno == ECONNABORTED || errno == ENETRESET)
Regards,
--
Daiki Ueno
>>>>> In <[EMAIL PROTECTED]>
>>>>> Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> Bruno Haible wrote:
> > Daiki Ueno wrote:
> >
> >> When I tried a tiny program which uses gnulib's poll(2) emulation on
> >> MacOS X 1
vel/gettext/gettext-tools/gnulib-lib/gl_list.h:557:
multiple definition of `gl_list_nx_create_empty'
.libs/gl_list.o:/home/ueno/devel/gettext/gettext-tools/gnulib-lib/gl_list.h:557:
first defined here
...
Can it be fixed by caller side?
Footnotes:
[1] http://gcc.gnu.org/gcc-4.3/porting_to.html
Regards,
--
Daiki Ueno
t is good to update
gnulib as well?
(I still don't fully understand the relationship between gnulib and
gettext, so perhaps I'm missing the point, but gettext-tools actually
seems to pick gnulib's {po,intl}.m4 through bison-i18n.)
Regards,
--
Daiki Ueno
lib/ref-del.sin -> gettext-runtime/intl/ref-del.sin (*)
lib/relocatable.h -> gettext-runtime/intl/relocatable.h (*)
lib/relocatable.c -> gettext-runtime/intl/relocatable.c (*)
lib/vasnprintf.c -> gettext-runtime/intl/vasnprintf.c (*)
lib/xsize.h -> gettext-runtime/intl/xsize.h (*)
Regards,
--
Daiki Ueno
Daiki Ueno writes:
> After the following change (in gnulib), locale_charset() returns "ASCII"
> on Mac OS X, even if thread's locale is set to "de_DE.UTF-8", say. So
> the solution would be either to make sure MB_CUR_MAX > 1 somehow in the
> test, or to
, I'm puzzled that this problem was discovered just now.
> Isn't there a similar problem with autopoint 0.18.1?
>
> Anyway, here's the patch I installed into gnulib.
Installed the following fix into gettext as well.
>From a071c8a3cdff4f6487390ceeb720cc9ae66e1474 Mon Sep 17 00:
ar xf gettext-0.18.2.tar.gz
$ cd getteext-0.18.2
$ patch -p1 < patch
$ pushd gettext-runtime/libasprintf
$ autoreconf -f
$ popd
$ CFLAGS= ./configure && make
I'm not 100% sure if this is the right fix, so Cc'ed bug-gnulib.
Footnotes:
[1] https://savannah.gnu.org/bugs/?37981
Regard
Paul Eggert writes:
> On 01/16/13 01:08, Daiki Ueno wrote:
>> I'm not 100% sure if this is the right fix, so Cc'ed bug-gnulib.
>
> This patch looks good to me. Might there be other files
> with the same problem? Maybe gettext should be changed to
> use gnulib-too
failed
Abort trap (core dumped)
FAIL: test-sigaction
It seems -fopenmp flag causes the error. It can also be reproduced
without openmp, but with CFLAGS="-O2 -pthread".
Regards,
--
Daiki Ueno
Paul Eggert writes:
> On 01/17/13 23:04, Daiki Ueno wrote:
>> It seems -fopenmp flag causes the error. It can also be reproduced
>> without openmp, but with CFLAGS="-O2 -pthread".
>
> I can't reproduce it with Fedora 17, but I guess that's not
> too
ra build log[1], FreeBSD 8.x does not seem
to have that behavior. Perhaps it might be a bug in the latest FreeBSD
kernel.
Footnotes:
[1] http://hydra.nixos.org/build/3910833/nixlog/1
Regards,
--
Daiki Ueno
n" error.
I'm attaching a patch.
Regards,
--
Daiki Ueno
>From e23bbce242682524d7b52a8637c92482d9a8c2fd Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Wed, 27 Mar 2013 17:16:46 +0900
Subject: [PATCH] wctype-h: fix gettext link error on mingw
Reported by Josue Andrade Gomes and Takay
Ed Maste writes:
> Tested on 8.4-PRERELEASE, 9.1-STABLE (the 9.x branch after 9.1
> released), and 10.0-CURRENT, all returned 0. Perhaps Daiki Ueno can
> test in the environment that originally demonstrated the problem.
I can still reproduce this on 9.1-RELEASE. Perhaps you ar
4
> --- a/lib/copy-acl.c
> +++ b/lib/copy-acl.c
> @@ -21,8 +21,7 @@
>
> #include "acl.h"
>
> -#include "acl-internal.h"
> -
> +#include "error.h"
Seems #include is also needed (same for set-acl.c).
Regards,
--
Daiki Ueno
always change it later if Daiki or Bruno prefers that.
FWIW, the change looks reasonable to me. Given that modules/gettext
adds AM_GNU_GETTEXT([external]) to configure.ac, the AM_CPPFLAGS setting
seems to be nothing more than example.
Regards,
--
Daiki Ueno
st the compiled binary on 10.6.
Regards,
--
Daiki Ueno
>From 19685cf6de36e6f09423edc059d7ba24c8b4e45a Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Sat, 11 May 2013 10:40:55 +0900
Subject: [PATCH] lock: work around pthread recursive mutexes bug in Mac OS X
10.6
* m4/lock.m4: Don't defi
Daiki Ueno writes:
> Patch attached.
Sorry, wrong patch. Please check the attached one instead.
I've confirmed that HAVE_PTHREAD_MUTEX_RECURSIVE is defined by default
on 10.8, but not with CFLAGS=-mmacosx-version-min=10.6.
Regards,
--
Daiki Ue
(_SC_OPEN_MAX) == 256
* OPEN_MAX == 10240
If I replace getdtablesize () with OPEN_MAX in the above call, the test
passes, while it still fails with OPEN_MAX - 1.
Regards,
--
Daiki Ueno
Paul Eggert writes:
> Thanks, I pushed the following to try to fix that.
> Does it work for you now?
Yes, all those 3 tests pass now. Thanks for the quick fix.
Regards,
--
Daiki Ueno
tion call with a yet undetermined callee
open (const char *__path, int __oflag, ...)
^
It seems that open cannot be directly passed to test_open as a function
pointer, since it is marked as always_inline. I'm attaching a patch.
Regards,
--
Daiki Ueno
>From f0ab4954d777a041c88964ce667a9
0:00 2001
From: Daiki Ueno
Date: Mon, 8 Jul 2013 09:39:05 +0900
Subject: [PATCH] gettext: Update to version 0.18.3.
* m4/intl.m4, m4/po.m4: Update from gettext-0.18.3. In particular,
require AC_PROG_SED to allow user to specify custom sed command when
generating en@quot PO file.
---
ChangeLog |
t;new->addfile(*IN)->hexdigest
: Digest::SHA1->new->addfile(*IN)->hexdigest);
Here, Digest::SHA1 package may be undefined. I'm attaching a patch.
As I'm new to Perl, comments (and a better fix) would be appreciated :)
>From 8726f48a1a263b528040f19a3323e2c558dba492
ext-related old patch, any
chance of this getting committed?
2012-12-20 Daiki Ueno
localecharset: make locale_charset thread-safe on Mac OS X
* lib/localcharset.c (locale_charset) [DARWIN7]: Use MB_CUR_MAX_L
instead of MB_CUR_MAX.
http://lists.gnu.org/archive/html/bug-gn
@@
+2013-08-24 Daiki Ueno
+
+ * m4/intl.m4: Update from gettext-0.18.3.1, which fixes a misuse
+ of AC_CHECK_DECLS.
+
2013-08-23 Paul Eggert
selinux-at: omit unnecessary include
diff --git a/m4/intl.m4 b/m4/intl.m4
index 959bd04..dffcd88 100644
--- a/m4/intl.m4
+++ b/m4
1 Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Tue, 26 May 2020 07:56:13 +0200
Subject: [PATCH] read-file: make use of fopen-gnu
* lib/read-file.c (read_file): Pass an 'e' flag to fopen.
(read_binary_file): Likewise.
* modules/read-file (Depends-on): Add fopen-gnu.
---
ChangeLog
avior enabled by default, but I worry that
it may cause any performance drawback.
Regards,
--
Daiki Ueno
>From d2fc964fa1dd87f5970f28c22349fb6983ff379e Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Tue, 26 May 2020 10:22:37 +0200
Subject: [PATCH] read-file: add variants that clear internal memor
ching a patch along
these lines.
Regards,
--
Daiki Ueno
>From 5a40a392b3b551cf92d4be022b4efd900f339e39 Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Tue, 26 May 2020 10:22:37 +0200
Subject: [PATCH] read-file: add flags to modify reading behavior
* lib/read-file.h (RF_BINARY, RF_SENSITI
t's do it.
> - The NEWS file needs an entry.
Indeed, I missed the last paragraph of your suggestion in the previous
mail; sorry about that. Here are the two separate commits for this.
>From 60608590e2b106708dd74fd31331567af5166d2e Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Wed, 27
has been fixed and pushed. Thank you for the review!
Regards,
--
Daiki Ueno
files
(OCSP response):
https://gitlab.com/gnutls/gnutls/-/jobs/569815031
It seems that the fopen module ignores a 'b' flag. The attached patch
fixes the failures.
Regards,
--
Daiki Ueno
>From 17fbb2560a05e3006125f8793c8e814ef5baa847 Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date:
Daiki Ueno writes:
> Bruno Haible writes:
>
>>> Here are proposed patches for other modules. Does this look right?
>>
>> There were no objections. I pushed the changes.
>
> Thank you for this. I have rebased GnuTLS on top of it, but noticed a
> strang
your patch is perfect.
Thank you for the review; fixed and pushed. Afterwards, I realized a
compilation error in the test code on FreeBSD, so I've added the
follow-up patch attached.
Regards,
--
Daiki Ueno
>From 9326739489050009e3b8834838abc02203c592e5 Mon Sep 17 00:00:00 2001
From: D
VE is set. I am attaching a patch for this.
>From 9165e495461db91b8abc42661fc543784d26d0d6 Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Fri, 29 May 2020 05:45:40 +0200
Subject: [PATCH] read-file: disable buffering if RF_SENSITIVE is set
* lib/read-file.c (read_file): Call setvbuf if RF_SENSITIVE.
meByHandleW'?
259 | || (GetFinalPathNameByHandleFunc != NULL
| ^~~~
| GetFinalPathNameByHandleW
Regards,
--
Daiki Ueno
ks, therefore it's OK.
>
> Also, in the specification of fread_file, I would add a note. Maybe like
> this?
Thank you, amended the documentation and pushed.
Regards,
--
Daiki Ueno
to make target 'parse-datetime-gen.h', needed by 'all'.
Stop.
make[2]: *** Waiting for unfinished jobs
YACC parse-datetime.c
make[2]: Leaving directory '/tmp/gnutls/build/src/gl'
make[1]: *** [Makefile:1761: all-recursive] Error 1
The a
>
> 2020-09-13 Bruno Haible
>
> parse-datetime: Make the build rule work with parallel 'make'.
> Reported by Daiki Ueno in
> <https://lists.gnu.org/archive/html/bug-gnulib/2020-09/msg00036.html>.
> * modules/parse-datetime (Makefile
"GNULIB_STRERROR" redefined [-Werror]
412 | #define GNULIB_STRERROR 1
|
conftest.c:305: note: this is the location of the previous definition
305 | #define GNULIB_STRERROR IN_GNUTLS_GNULIB_TESTS
|
cc1: all warnings being treated as errors
Could anyone shed some light on this?
Regards,
--
Daiki Ueno
worked:
https://gitlab.com/gnutls/gnutls/-/merge_requests/1345/diffs?commit_id=1fc78a5a3e6646e4082be7ec1c4d60b9d40213d0
Regards,
--
Daiki Ueno
>From 69b8df2c5b011b09c8d03c13566356a906bd89dc Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Sat, 21 Nov 2020 17:32:58 +0100
Subject: [PATCH] read-file: remove dead assignment
* lib/read-file.c (fread_file): Remove dead assignment when
RF_SENSITIVE is set, flagged by clang-analy
efore I would like to ask your permission to change it
to "LGPLv2+". Would you agree with that?
Footnotes:
[1] https://lists.gnu.org/archive/html/bug-gnulib/2017-08/msg00057.html
[2] https://gitlab.com/gnutls/gnutls/-/issues/1179
Regards,
--
Daiki Ueno
oesn't fully resolve the issue with DTLS tests as mentioned, and I
suspect there might be some other confusions. Any suggestions would be
appreciated.
Footnotes:
[1] https://gitlab.com/dueno/gnutls/-/jobs/2613997489
Regards,
--
Daiki Ueno
>From eac9e4fe9fd9e432bce8765059ae29559258344f Mon
Paul Eggert writes:
> On 9/25/22 21:56, Daiki Ueno wrote:
>> I guess a simple solution would be to swap the order of
>> gl_YEAR2038_EARLY and AC_SYS_LARGEFILE in modules/largefile, as with the
>> attached patch.
>
> Thanks, I installed that.
>
>> This doesn
well?
Sure, I agree with that change.
Regards,
--
Daiki Ueno
t see such changes since 0.9.8. Could you elaborate why
this change is appropriate, for future improvements of the release
process?
Regards,
--
Daiki Ueno
(0.9.10 is not released)?
I was confused because you urged a new release for this:
https://lists.gnu.org/archive/html/bug-libunistring/2018-04/msg3.html
And if it is the case, my answer again would be "not this time", because
the fix in the Gnulib git should be sufficient.
Regards,
--
Daiki Ueno
of the gettext, which
is somehow guaranteed to compile.
Therefore, if the new script provides a similar feature, without adding
a manual process to our current practice, I wouldn't oppose. Otherwise
it seems like a bit of a step back to me.
Regards,
--
Daiki Ueno
quot;D" mode on Windows, which implies the file will be
deleted on close (fwriteerror_temp here). Thus, after calling
write_temp_file, the file will be deleted immediately. Maybe we should
use plain fopen/fwriteerror here?
Regards,
--
Daiki Ueno
, I found cleanup_temp_dir is missing in a few places in
javacomp.c. See the second patch for that.
Regards,
--
Daiki Ueno
>From 54c6e156989df415c53d44fb516d3b545b2ed80a Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Sun, 22 Sep 2013 18:50:43 +0900
Subject: [PATCH 1/2] javacomp: make co
gettext-0.19 (and 0.19.1) has been released a while ago, this is the
update of the M4 macros. There's no difference between 0.19 and 0.19.1.
>From e3fd44d010a9eb0afb52d091268c80e8ac61e306 Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Wed, 11 Jun 2014 18:06:11 +0900
Subject: [PATCH]
nt than as part of
gnulib.
Regards,
--
Daiki Ueno
ement happens because of some Gnulib tests depending on
the gettext module. How about removing the dependencies?
>From c6e5277472b17de2a98e5e5c903b36efab7a039b Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Thu, 10 Jul 2014 07:24:04 +0900
Subject: [PATCH] tests: remove dependency on gettex
ch as a proof of concept.
>From 875d647f9bb0ffc8f8b507083cff737c56f3a9e8 Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Thu, 10 Jul 2014 13:35:57 +0900
Subject: [PATCH] gettext: move libintl check to gettext-h
The gettext module copies the entire gettext infrastructure,
including po/ directory handling, etc
ts.gnu.org/archive/html/bug-gettext/2014-06/msg00021.html
--
Daiki Ueno
Bernhard Voelker writes:
> On 07/11/2014 03:13 PM, Daiki Ueno wrote:
>> Could you provide an example of the build failures with 0.19.1?
>
> https://build.opensuse.org/package/live_build_log/Base:System/coreutils/openSUSE_Factory/i586
>
> [ 172s] *** Error in `/usr/b
mpat with 2.68
>> else
>> rely on autopoint avoiding m4 include errors
>> This autopoint code though relies on autoconf >= 2.69
>> fi
I've pushed a fix for this anyway:
http://git.savannah.gnu.org/cgit/gettext.git/commit/?h=maint&id=e1bd11a1
Regards,
--
Daiki Ueno
Hi,
Daiki Ueno writes:
> The 'announce-gen' script fails when Digest::SHA (not Digest::SHA1) is
> installed:
>
> Can't locate object method "new" via package "Digest::SHA1" (perhaps you
> forgot to load "Digest::SHA1"?) at
AIL: autopoint-2
> FAIL: autopoint-3
Yes, the patch was incomplete and here is the amendment:
http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=db326c5a
I forgot that AM_GNU_GETTEXT{,_VERSION} cannot be captured by autoconf
trace. 0.19.2 released today shouldn't have the issue.
Regards,
--
Daiki Ueno
ter ideas?
Regards,
--
Daiki Ueno
his change? I don't even know if Guile is still using the
packaged libunistring.
By the way, isn't there a minor race in gl_locale_name_thread, since it
depends on a global variable found_lcid?
Regards,
--
Daiki Ueno
ulib has glthread/tls but I'm not sure if it is
worth adding another dependency to localename.c (which is also shared
with libintl...) for this specific issue.
Maybe just lock around the use?
Regards,
--
Daiki Ueno
(< 3.3?), or might require extra compiler options or
runtime dependency:
http://sourceforge.net/p/mingw/bugs/1333/
http://sourceforge.net/p/mingw-w64/mailman/message/31213279/
I could be wrong and perhaps it might not be a problem with the recent
MinGW releases.
Regards,
--
Daiki Ueno
Daiki Ueno writes:
> I could be wrong and perhaps it might not be a problem with the recent
> MinGW releases.
FWIW I just tried myself (on wine, though) and it seems to work with:
- GCC 4.8.3 (Fedora mingw64-gcc package, cross compiling)
- GCC 4.7.2 (mingw-w32-bin_i686-mingw_20111219
t's best to use them.
Yes, could you create a patch in that direction? By the way, though a
minor nitpicking, the indentation in gl_locale_name_thread still doesn't
look correct (there is a variable declaration in the middle of block).
Regards,
--
Daiki Ueno
to gnulib? But the problem
> should be fixed in the upstream version anyway.
As far as I checked, gettext uses build-aux/install-reloc from Gnulib as
it is, and the patch still applies to the Gnulib master.
Regards,
--
Daiki Ueno
on?
>
> Will do.
Here is a simple patch for this. Is it OK for you?
>From a9576350604e97fc3c3fa16778e6e3d10094f97a Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Thu, 7 Aug 2014 08:46:52 +0900
Subject: [PATCH] localename: make gl_locale_name_thread really thread-safe on
Windows
* lib/
Paul Eggert writes:
> Daiki Ueno wrote:
>> As far as I checked, gettext uses build-aux/install-reloc from Gnulib as
>> it is, and the patch still applies to the Gnulib master.
For the record, porting it to Gnulib was completed in 2007:
http://git.sv.gnu.org/cgit/gettext.git/comm
how the gnulib option for that was supposed to work.
Are you going to add "unsafe" version later, or is it not useful at all?
Thanks,
--
Daiki Ueno
Ben Pfaff writes:
>>> Are you going to add "unsafe" version later, or is it not useful at all?
>>
>> I do not have a use myself for unsafe versions, but I will add them if
>> you think they are a good idea. Let me know.
>
> What is your opinion on this issue?
Oh, sorry, it wasn't my intention t
input + 2, 7, &state);
ASSERT (ret == 1);
However, "\271\201" is a valid GB18030 sequence which encodes U+7B92.
Maybe it should expect ret == 2?
Footnotes:
[1] http://docs.oracle.com/cd/E36784_01/html/E36874/mbrtowc-3c.html
Regards,
--
Daiki Ueno
ls.
Thanks for tracking it down. I've applied the patch and confirmed it
effectively fixes the problem.
Regards,
--
Daiki ueno
Daiki Ueno writes:
> The latter case checks if the return value of mbrtowc, when scanning a
> string starting with "\271\201", under the zh_CN.GB18030 locale.
>
> char input[] = "B\250\271\201\060\211\070er";
> memset (&state, '\0', sizeof (m
/html/bug-gettext/2013-11/msg00020.html
though it is a different (multi-threaded consumer) case.
Thanks,
--
Daiki Ueno
yright assignment
from the original author (Cc'ed).
>From d8e9c96ef0c1e1c1c410cfbaec547c2e3d442dbe Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Tue, 14 Oct 2014 12:47:06 +0900
Subject: [PATCH] localename: Avoid implicit thread creation in CoreFoundation
Problem reported by Peter Eisentr
gt; the forked version, as this isn't a function that would
> be in a hot path.
I agree, since this function is mainly called from libintl_setlocale,
which is called at very early stage in typical programs, and probably we
can assume that there is only one thread at that point.
Regards,
--
Daiki Ueno
f the iconv
function works properly, maybe a workaround would be to use the fixed
prototype of iconv (as attached)? I'm still not able to reproduce the
original error on my MinGW environment, though.
Regards,
--
Daiki Ueno
>From 39e7957f1f724ae39524a82c230441df2557686c Mon Sep 17 00:00:00
Daiki Ueno writes:
> Given that the intention of the above test is to check if the iconv
> function works properly, maybe a workaround would be to use the fixed
> prototype of iconv (as attached)?
Sorry, that was obviously wrong. The other idea is to suppress the
error with a prag
r idea is to suppress the
>> error with a pragma, but I guess it would be better to actually
>> check the prototype in AM_ICONV_LINK.
>
> What about using m4_foreach, running the link tests with and without
> `const'?
Thanks for the tip. The attached p
before/after the change, using test packages:
Before: http://du-a.org/~ueno/junk/test-iconv-0.tar.gz
After: http://du-a.org/~ueno/junk/test-iconv-1.tar.gz
Thanks,
--
Daiki Ueno
>From 46969a8560460084f6770f3c21025f0faac33f9f Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Tue, 21 O
#x27;ve tested it on MSYS after manually adding 'const' to the iconv
declaration in /usr/local/include/iconv.h, and it seems to be detected.
Here is a new test package:
http://du-a.org/~ueno/junk/test-iconv-2.tar.gz
Thanks,
--
Daiki Ueno
>From 621cb2d9483053aa33cfeb1c6c6c20316aeac
on is also available:
ftp://alpha.gnu.org/gnu/libunistring/libunistring-0.9.5-alpha3.tar.xz
I'd really appreciate if someone could go through the patches and find
any mistakes before committing. Thanks in advance.
Daiki Ueno (10):
gen-uni-tables: Minor style fixes
gen-uni-tables: Ch
* lib/gen-uni-tables.c: Escape newlines in the Emacs file local
variables specification.
(is_outdigit): Comment out the unused function.
---
lib/gen-uni-tables.c | 43 ++-
1 file changed, 22 insertions(+), 21 deletions(-)
diff --git a/lib/gen-uni-tables.c b
* lib/uniwbrk/u-wordbreaks.h (FUNC): Ignore Extend and Format
characters if the previous character property is one of
WBP_NEWLINE, WBP_CR, and WBP_LF.
---
lib/uniwbrk/u-wordbreaks.h | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/lib/uniwbrk/u-wordbreaks.h b/lib/uniwbr
* tests/uniwbrk/test-uc-wordbreaks.c
(wordbreakproperty_to_string): Support WBP_DQ, WBP_SQ, and WBP_HL.
* lib/uniwbrk.in.h (WBP_DQ, WBP_SQ, WBP_HL): New enumeration values.
* lib/uniwbrk/u-wordbreaks.h (FUNC): Support WB7a, WB7b, and WB7c.
Update WB5, WB6, WB7, WB9, WB11, WB12, WB13a, and WB13b.
*
The uniname module tries to reduce memory usage by grouping Unicode
codepoints so that each codepoint fit into a 16-bit integer (4-bit tag
plus 12-bit index). However, this transformation cannot represent all
the characters in Unicode 7.0, where > 16 groups are needed.
The attached patch tries to
FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
+/* Written by Daiki Ueno
* lib/unilbrk/lbrktables.h (LBP_RI): New enumeration value.
(unilbrk_table): Adjust table size.
* lib/unilbrk/lbrktables.c (unilbrk_table): Add a row and column
for LBP_RI.
* lib/uniwbrk.in.h (WBP_RI): New enumeration value.
* lib/uniwbrk/u-wordbreaks.h (FUNC): Support rule WB13c.
Normalize table
* lib/unictype/joininggroup_byname.gperf: Add Rohingya Yeh
joining group name.
* lib/unictype/joininggroup_name.h: Likewise.
* lib/unilbrk/lbrktables.h (LBP_HL): New enumeration value.
(unilbrk_table): Adjust table size.
* lib/unilbrk/lbrktables.c (unilbrk_table): Add a row and column
for LBP_HL.
* lib/gen-uni-tables.c (output_joining_group): Switch to
3-level table to accommodate a joining group defined with higher
code-point value. Since there are only 88 groups defined in
Unicode 7.0.0, use 7-bit packed format for level3 entries.
* lib/unictype/joininggroup_of.c (uc_joining_group): Adju
* lib/gen-uni-tables.c (output_category, output_bidi_category)
(output_joining_type, output_ident_category): Check out-of-range
values added to 3-level tables.
---
lib/gen-uni-tables.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/lib/gen-uni-tables.c b/lib/gen-uni-tables.c
in
ems to be detected.
>>
>> Here is a new test package:
>> http://du-a.org/~ueno/junk/test-iconv-2.tar.gz
>
> Thanks, this works.
Thanks for testing, pushed.
Regards,
--
Daiki Ueno
ks. Will fix those in the next update. Also, I wasn't aware that a
manual update is needed for uniwidth/width.h; that will be fixed as
well.
Regards,
--
Daiki Ueno
r under Japanese
locale.)
Perhaps it would be good to replace mbrtowc on Solaris, though I have no
idea how to detect the wrong behavior without depending on particular
locale data. Alternatively, we could simply ignore this test failure on
Solaris, since the tested calling convention is not very common.
Thoughts?
Regards,
--
Daiki Ueno
Daiki Ueno writes:
> Paul Eggert writes:
>
>> On 10/23/2014 04:43 AM, Pádraig Brady wrote:
>>> Except for the assert() nit, I can't find any issues.
>>
>> My only nit was adding the "#if 0"; might as well just delete the code
>> instea
e to wait.
As I'm getting more reports (perhaps) related to this, I've filed a bug
at the FreeBSD bugzilla, with a reproducer written in plain pthreads:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195098
Regards,
--
Daiki Ueno
I've also uploaded a test package at:
http://du-a.org/~ueno/junk/test-pipe-filter-ii-aix.tar.gz
Regards,
--
Daiki Ueno
>From 17a0216558375b833ca11adeb39eedd42fbd42e3 Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Tue, 18 Nov 2014 21:11:09 +0900
Subject: [PATCH] pipe-filter-gi, pipe-f
Daiki Ueno writes:
> On AIX 7.1, 'select' is defined as static and cannot be referred
> from inline function.
> * lib/pipe-filter-aux.h (nointr_select): Remove, manually expand
> the definition...
> * lib/pipe-filter-gi.c (filter_loop): ...here, and...
ould rather prefer Gnulib modules. Does anyone
know what's the rationale behind this?
Regards,
--
Daiki Ueno
>From 1125daef9fc55de5af4fd9ebd71cc63a26c5051b Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Thu, 27 Nov 2014 16:46:38 +0900
Subject: [PATCH] uniname/uniname-tests: skip if system
el, based on
whether the Gnulib module is compiled).
Regards,
--
Daiki Ueno
>From 72d21c164fe1ab24b508f770f436d3ceacbefeec Mon Sep 17 00:00:00 2001
From: Daiki Ueno
Date: Thu, 27 Nov 2014 18:46:43 +0900
Subject: [PATCH] uniname/uniname-tests: skip if system's libunistring is used
* modules/uniname
1 - 100 of 163 matches
Mail list logo
