> vasnprintf: Work around two grouping bugs on many platforms.
The tests fail on native Windows, because MSVC does not support the
grouping flag at all, and because mingw uses the decimal point instead
of the thousands separator, for integers.
Many *printf implementations have bugs in the implementation of the "'" flag,
that is supposed to add thousands separators between digits.
One of these bugs became apparent when testing coreutils-9.7 across platforms.
The other one is much more insidious, and affects even relative
This patch implements a portable duplocale() function, that matches the
just-added newlocale() function. Part of the code was already there,
for old glibc and old AIX platforms.
2025-02-14 Bruno Haible
duplocale: Support all platforms.
* lib/locale.in.h (duplocale): Declare
* lib/dirent.in.h (DT_UNKNOWN, DT_FIFO, DT_CHR, DT_DIR, DT_BLK)
(DT_REG, DT_LNK, DT_SOCK, DT_WHT): Define these on all platforms,
if the system does not already define them. Check that they
have distinct values.
(_GL_DIRENT_S_ISWHT, _GL_DIRENT_S_IFWHT) [!(IFTODT && DTTOIF)]:
New macros.
Collin Funk wrote:
> Since termios.h defines 'struct winsize' on all platforms I think that
> pty.h should also do the same.
Yes, given the description of in
https://www.gnu.org/software/libc/manual/html_node/Pseudo_002dTerminal-Pairs.html
this seems reasonable.
> I've
Since termios.h defines 'struct winsize' on all platforms I think that
pty.h should also do the same. I've committed a patch doing that and
adding a basic C check program for types.
BTW, I think this fixes a very minor bug. Since the 'pty' module does
not directly depend
Hi Collin,
> I haven't tested other platforms yet but hopefully it should all be
> handled in termios.h there or through a single #include like glibc.
AIX is like glibc, here:
$ echo '#include ' | $CC -E - | grep winsize
$ echo '#include ' | $CC -E - | grep w
Hi,
A prerequisite of implementing tcgetwinsize and tcsetwinsize as
specified by POSIX 2024 is defining struct winsize on all platforms in
termios.h.
This patch defines the struct on Windows where it is missing and checks
if it is defined in sys/ioctl.h like glibc. POSIX 2024 states that it
I wrote:
> The continuous integration of Gnulib for many platforms is now operational.
> <https://github.com/gnu-gnulib/ci-testdir-check/actions>
Let me document it in the HACKING file.
2024-06-07 Bruno Haible
Update HACKING.
* HACKING: Mention the new ma
Hi Bruno,
Bruno Haible writes:
> Yes and no. This mailing list has quite a wide audience. I don't want to
> have lots of chatter about CI details on this list. Therefore, what belongs
> on this list is:
> - Discussion whether a certain failure is a platform bug, a Gnulib code
> bug, a Gnul
Collin Funk wrote:
> Now we should be able to catch errors quickly as things update, etc.
Right. With this multi-platform-CI is it now easier to add a unit test:
Just make sure that it follows the specification and works on two or three
platforms, commit it, and then we'll see (within a
Hi Bruno,
Bruno Haible writes:
> The continuous integration of Gnulib for many platforms is now operational.
> <https://github.com/gnu-gnulib/ci-testdir-check/actions>
>
> It tests a testdir of nearly all modules of Gnulib on the following platforms:
Thanks! It already seem
Hi Eli,
Eli Zaretskii writes:
> Since this was brought up (and comes up from time to time), and since
> Collin here is listening as well, let me explain the issues we have
> with Gnulib in Emacs on MS-Windows.
>
> The main point to keep in mind is that Emacs is still striving to
> support very o
On Thu, Jun 6, 2024 at 5:34 PM Bruno Haible wrote:
>
> The continuous integration of Gnulib for many platforms is now operational.
> <https://github.com/gnu-gnulib/ci-testdir-check/actions>
Congrats. That is a great accomplishment.
Jeff
The continuous integration of Gnulib for many platforms is now operational.
<https://github.com/gnu-gnulib/ci-testdir-check/actions>
It tests a testdir of nearly all modules of Gnulib on the following platforms:
- Ubuntu GNU/Linux 22.04
- CentOS 7
- Alpine Linux
- macOS 11, 12, 1
> Date: Wed, 5 Jun 2024 11:45:07 -0700
> Cc: bug-gnulib@gnu.org
> From: Paul Eggert
>
> On 2024-06-05 09:22, Bruno Haible wrote:
>
> > why not choose the Gnulib approach, namely to let the 'locale'
> > module provide the replacement if this header file is missing?
>
> Because that would drag in
On 2024-06-05 12:48, Bruno Haible wrote:
Please, can you ask? Thanks.
Done here:
https://lists.gnu.org/r/emacs-devel/2024-06/msg00059.html
Feel free to join that thread.
Paul Eggert wrote:
> As I mentioned since we're close to branching off for a release, I'm a
> bit reluctant to mess with this stuff right now.
Asking questions should be permitted at any time. Eli only doesn't
want "us to destabilize the master branch".
If you don't want to ask, can you please p
On 2024-06-05 11:59, Collin Funk wrote:
An old 4.4BSD archive that I have has locale.h so I imagine it is pretty
rare.
Yes, it dates back at least to the 1980s. But Emacs (also created in the
1980s) was designed to port to ancient platforms that are oddball by
today's standards, and
Paul Eggert wrote:
> > Which platform is this?
>
> Don't know offhand. I could ask.
Please, can you ask? Thanks.
> Right now Emacs is starting to freeze up for cutting off the next branch
> and I expect people would not be interested in changing this crufty old
> stuff right now. Probably bett
Hi Paul,
Paul Eggert writes:
>> Which platform is this?
>
> Don't know offhand. I could ask.
An old 4.4BSD archive that I have has locale.h so I imagine it is pretty
rare.
> Right now Emacs is starting to freeze up for cutting off the next
> branch and I expect people would not be interested i
On 2024-06-05 09:22, Bruno Haible wrote:
Which platform is this?
Don't know offhand. I could ask.
Right now Emacs is starting to freeze up for cutting off the next branch
and I expect people would not be interested in changing this crufty old
stuff right now. Probably better to ask later.
Paul Eggert wrote:
> Thanks, looks good except that Emacs attempts to be portable to
> platforms lacking .
It's the first time I hear about such platforms in ca. 20 years.
In Gnulib, we're assuming that exists since 2011:
https://git.savannah.gnu.org/gitweb/?p=gnuli
Collin Funk wrote:
> I feel like MacOS will probably be problematic. I can see that it
> already caused you a lot of trouble [1].
>
> [1] https://lists.gnu.org/archive/html/bug-gnulib/2024-05/msg00330.html
macOS has some amount of problems, roughly like AIX or Android.
What we try to do (in Gnul
Paul Eggert wrote:
> > $ gcc -Wall -S foo.c
> > foo.c:1: warning: integer constant is too large for ‘long’ type
>
> I don't see how that would produce incorrect code for byteswap.h.
Indeed, gcc 4.4.7 warns but produces a long long value (no truncation).
> The longer story is C89 lacked 'long lon
On 2024-05-17 16:51, Bruno Haible wrote:
-- foo.c --
unsigned long long x = 0xff00;
---
$ gcc -Wall -S foo.c
foo.c:1: warning: integer constant is too large for ‘long’ type
I don
On 5/17/24 3:49 PM, Paul Eggert wrote:
> POSIX does not require uint64_t, and the C standard
> does not require uint16_t or uint32_t either, so port
> to platforms that lack these types. The POSIX limitation
> is the only significant one in practice. I ran into this
> issue when
On 5/17/24 4:51 PM, Bruno Haible wrote:
> I think this produces wrong code with gcc 4.4.7 and older. See:
>
> -- foo.c --
> unsigned long long x = 0xff00;
> ---
>
> $ gcc -Wall -S f
Paul Eggert wrote:
> -#else
> - return x) & 0xff00ull) >> 56)
> - | (((x) & 0x00ffull) >> 40)
> - | (((x) & 0xff00ull) >> 24)
> - | (((x) & 0x00ffull) >> 8)
> - | (((x) & 0xff00ull) << 8)
> -
POSIX does not require uint64_t, and the C standard
does not require uint16_t or uint32_t either, so port
to platforms that lack these types. The POSIX limitation
is the only significant one in practice. I ran into this
issue when updating Emacs, which still ports to platforms
lacking 64-bit
Port to theoretical platforms that C and POSIX allow but are not
likely to ever exist. This is mostly just to document the existing
source code: when optimizing, the machine code should be largely
unchanged even on platforms lacking __builtin_clz etc.
* lib/stdbit.in.h: Omit static_assert that
This patch updates the list of target platforms. What has changed since last
year:
- I cannot claim to be testing RHEL any more, since I don't have access
to a copy of it and since the previous clones (CentOS, AlmaLinux etc.)
can no longer sync with RHEL, due to [1].
- Free
When a program calls setlocale() with some argument that is not reflected in
the environment variables, ideally the gl_locale_name function should return
that locale.
Currently this is enabled only for glibc systems. But it is actually possible
to do the same thing on some other platforms as well
I'm seeing link errors of the 'asyncsafe-spin' unit tests on two platforms:
* On an older Linux/arm system (with glibc, gcc 4.2.3 arm-none-linux-gnueabi):
gcc -std=gnu99 -Wno-error -g -O2 -o test-asyncsafe-spin1
test-asyncsafe-spin1.o libtests.a ../gllib/libgnu.a libte
are implemented by a software library, not by the hardware.
2023-11-06 Bruno Haible
snan: Add more info for mips-based platforms.
* m4/nan-mips.m4: New file.
* lib/snan.h: Add comments regarding mips.
* modules/snan (Files): Add m4/nan-mips.m4.
(confi
I had made a mistake in the override code for powerpc. This patch fixes it.
2023-11-04 Bruno Haible
fenv-exceptions-trapping: Fix for powerpc* platforms.
* lib/fenv-except-trapping.c (feenableexcept, fedisableexcept)
[powerpc]: Use the correct bit mask for the trap
And here's a unit test, to protect against further occurrences of the same bug:
2023-08-15 Bruno Haible
readutmp tests: Add test against today's bug.
* tests/test-readutmp.c (main): Verify that there is exactly one
BOOT_TIME entry.
diff --git a/tests/test-readutmp.c b
On OpenBSD, 'test-readutmp' prints two entries of type BOOT_TIME. The second
one should not be present, since it is only a fallback. The cause is that
have_boot_time always returns false.
This patch fixes it.
2023-08-15 Bruno Haible
readutmp: Fix for platforms witho
Like wcscmp(), wcsncmp() has two ISO C compliance bugs on several platforms.
These two patches provide the workaround.
In particular, the module 'wcsncmp' is no longer obsolete.
2023-04-19 Bruno Haible
wcsncmp: Add tests.
* tests/test-wcsncmp.c: New file, base
These two patches work around an ISO C compliance bug of wcscmp()
on several platforms, and another one specific to AIX.
The point is that in ISO C, a "wide character" is any wchar_t value.
A "wide character" is not constrained to the range 0..INT_MAX. For
the precise r
These two patches work around an ISO C compliance bug of wmemcmp()
on several platforms.
The point is that in ISO C, a "wide character" is any wchar_t value.
A "wide character" is not constrained to the range 0..INT_MAX. For
the precise reasoning, see
<https://www.openwall
On 11/04/23 18:58, Paul Eggert wrote:
> On 4/11/23 06:45, Adhemerval Zanella Netto wrote:
>
>> It makes difference on all ABIs with has originally 32 bit time_t support:
>> i686, microblaze, arm, m68k, sh, csky, nios2, and hppa, powerpc32, sparc32,
>> s390, and mips o32.
>
> Thanks, I installe
2, ork1, riscv32 and x86_64-x32,
@item
NetBSD 6.0 (2012) and later on x86 and sparc,
@item
@@ -81,6 +81,8 @@ platforms or ABIs:
@itemize
@item
+Android,
+@item
Mac OS X 10.6 (2009) and earlier on x86 and powerpc,
@item
GNU/Hurd/x86,
--
2.39.2
/releases.html> says that musl uses 64-bit time_t on
> all architectures starting with 1.2.0.
>
>> +@item
>> +Cygwin/x86,
>
> Cygwin dropped 32-bit support last year (3.3.6 is the last version with x86),
> so this could use a date. Come to think of it, other entries
her entries could
use dates too.
+Whereas no failure will occur on the following 32-bit platforms or ABIs:
+@itemize
+@item
+Linux/x86 with glibc >= 2.34 on
+x86, arm, mips (32-bit or n32 ABI), powerpc, sparc, s390, hppa, m68k, sh,
csky, microblaze, nios2,
I vaguely recall someone tell
To test the new largefile + year2038 changes, I created a gnulib testdir
./gnulib-tool --create-testdir --dir=../testdir --single-configure
largefile-required year2038-required
and compiled it on various platforms. Here are the results, by ABI:
i386 Linux: Ubuntu 22.04 OK
Now, on Solaris 11.3 with gcc, I see a warning
../../gllib/vasnprintf.c:275:25: warning: implicit declaration of function
‘wcsnlen’ [-Wimplicit-function-declaration]
I don't know whether that's a Solaris 11 bug or a GCC installation/configuration
problem. Anyway, this simple patch fixes it.
20
On OpenBSD, I'm now seeing a "warning: unused function local_wcsnlen".
Also, on some platform, there is a warning about an unused variable
'has_precision'.
This patch fixes both.
2023-03-22 Bruno Haible
vasnwprintf: Fix a "warning: unused function local_wcsnlen".
* lib/vasnpr
round, I'll just not use swprintf on these platforms.
For musl libc, I have reported it at
<https://www.openwall.com/lists/musl/2023/03/22/9>.
- For mingw, I'll continue to use the snwprintf function, but with a small
workaround.
2023-03-22 Bruno Haible
vasnwprintf: F
Yesterday I did:
> * modules/vasnwprintf (Depends-on): Add mbrtowc. Remove mbsrtowcs.
This causes link errors on AIX 7.1, such as:
xlc -q64 -qthreaded -qtls -g -L/home/haible/prefix64/lib -o
test-vasnwprintf-posix test-vasnwprintf-posix.o libtests.a ../gllib/libgnu.a
libtests.a ../gllib
onversion from TCHAR_T[] to DCHAR_T[] must not stop at NUL bytes.
It needs to convert the entire output of snprintf.
The new unit tests for the %c and %lc directives trigger these bugs.
Fixed as follows.
2023-03-21 Bruno Haible
vasnwprintf: Fix for older platforms without
After adding a few more tests for *printf %c and %lc, I noticed yet another
*printf bug. This time not in musl libc, but in _all_ platforms other than
musl libc.
For glibc, I registered it as
https://sourceware.org/bugzilla/show_bug.cgi?id=30257 .
This patch adds a workaround to the (narrow
On platforms without swprintf, such as IRIX 6.5, I was seeing this warning,
and later a link error:
In file included from ../../gllib/vasnwprintf.c:18:
../../gllib/vasnprintf.c: In function `vasnwprintf':
../../gllib/vasnprintf.c:3509: warning: implicit declaration of function
`swprintf&#
+-
2 files changed, 48 insertions(+), 25 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 98fef6c6c..3027aa45f 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,15 @@
+2021-08-02 Paul Eggert
+
+ year2038: port to unusual time_t platforms
+ * m4/year2038.m4
* tests/test-reallocarray.c (main): Don’t assume that
PTRDIFF_MAX / 2 + 1 <= SIZE_MAX. POSIX allows platforms
where this isn’t true, though I don’t know of any examples.
---
ChangeLog | 5 +
tests/test-reallocarray.c | 9 ++---
2 files changed, 11 insertions(+)
Paul Eggert wrote:
> That looks good, thanks. And thanks for all the work with libsigsegv.
Pushed.
Bruno
That looks good, thanks. And thanks for all the work with libsigsegv.
ibc > 2.33 snapshot
- Solaris 11/sparc64
- Cygwin
- Minix (just to test a case where catching stack overflow is not supported).
And I had tested the 'sigsegv' module on ca. 58 platforms, from IRIX 6.5 to
musl libc on Linux/s390x.
Bruno
>From 7832467d9d79753185664f702c50fb91dd
ore complex than needed.
2020-12-18 Bruno Haible
free: Remove support for obsolete platforms.
* m4/free.m4 (gl_FUNC_FREE): Assume free(NULL) works. Don't define
CANNOT_FREE_NULL.
* lib/free.c (rpl_free): Don't test CANNOT_FREE_NULL.
* m
functionality (e.g. those that define 'uc_is_alnum'
etc.) are not being built.
This patch should fix it.
2020-11-16 Bruno Haible
Fix link errors on platforms with libunistring.
* modules/c32isalnum (Link): New section.
* modules/c32isalnum-tests (Makefile.am): Link test-
-23 Paul Eggert
+
+ regex: port to weird isascii platforms
+ * lib/regex_internal.h (isascii) [!_LIBC]: Supply glibc version.
+
2020-09-20 Norihiro Tanaka
dfa: make dfasupported a global function
diff --git a/lib/regex_internal.h b/lib/regex_internal.h
index dbc503cd5
uot;)", -)
^~~~
../../gltests/verify.h:229:41: note: expanded from macro '_GL_VERIFY'
# define _GL_VERIFY(R, DIAGNOSTIC, ...) _Static_assert (R, DIAGNOSTIC)
^ ~
1 error generated.
This pat
Platforms that don't have the functions
memcmp
memcpy
memmove
memset
memchr
dup2
getcwd
were seen in the years 1990..1995, but had already disappeared around 2000.
There's no reason to keep the code for these obsolete platforms now,
20 years later.
2020-07-07 Br
Jeffrey Walton wrote:
> On Apple platforms, when targeting specific devices like AppleTV, you
> should include Apple's .
>
> You will also need to determine platform
> support for function calls like fork(). Not all Apple platforms
> provide fork and friends.
In GNU, we d
Paul Eggert wrote:
> On 1/26/20 1:42 AM, arn...@skeeve.com wrote:
> > And then in places in regcomp.c BITSET_WORD_BITS is tested in
> > several #if/#elif statements.
>
> Ouch, I hadn't noticed that. It's exercised only on non-GCC platforms
> that don't
On 1/26/20 1:42 AM, arn...@skeeve.com wrote:
And then in places in regcomp.c BITSET_WORD_BITS is tested in
several #if/#elif statements.
Ouch, I hadn't noticed that. It's exercised only on non-GCC platforms
that don't support INT_WIDTH etc., which is why I didn't see
Hi. Paul.
> diff --git a/lib/regex_internal.h b/lib/regex_internal.h
> index 13e15e21e..6d436fde1 100644
> --- a/lib/regex_internal.h
> +++ b/lib/regex_internal.h
> @@ -141,6 +141,9 @@
> #ifndef SSIZE_MAX
> # define SSIZE_MAX ((ssize_t) (SIZE_MAX / 2))
> #endif
> +#ifndef ULONG_WIDTH
> +# defin
Paul Eggert wrote on 2019-12-26:
> +unsigned int wc
> + = (((unsigned int) (c & 0x0f) << 12)
> + | ((unsigned int) (c2 ^ 0x80) << 6)
> + | (unsigned int) (c3 ^ 0x
Paul Eggert wrote:
> wchar_t is too narrow to represent all the Unicode characters,
> consider a byte sequence for an out-of-wchar_t-range character to
> be an encoding error.
Thanks. I had not thought about 16-bit wchar_t when writing this code.
For supporting full Unicode on AIX and Windows pla
* lib/mbrtowc.c (mbrtowc): On platforms like AIX 7.2, where
wchar_t is too narrow to represent all the Unicode characters,
consider a byte sequence for an out-of-wchar_t-range character to
be an encoding error. This fixes grep’s surrogate-pair test
failure on AIX 7.2.
---
ChangeLog | 9
Paul Eggert wrote:
> Thanks, removing that old cruft looks good to me too.
Done. Likewise for the mentions of BSDI, BSD/OS, and Tandem/NSK.
Also fixed a doc mistake:
2019-07-06 Bruno Haible
error: Fix documentation.
* doc/glibc-functions/error_at_line.texi: Document what th
Thanks, removing that old cruft looks good to me too.
At some point someone with energy could remove the corresponding code (as the
'configure' delay can be bothersome) but that's low priority.
Hi,
I'd like to remove the mentions of the following old platforms from
the gnulib documentation:
Platform Comments
glibc < 2.2
Linux libc5
Mac OS X < 10.5
AIX < 5 end of support in 2004 (AIX 4.3.3 released in 1999)
HP-UX < 11
> 2019-02-23 Bruno Haible
>
> relocatable-prog: Use wrapper-free installation also on Mac OS X.
> Reported by Paul Smith .
> * build-aux/install-reloc: Accept a 'mode' argument as first argument.
> (func_relativize): New function, from gnulib-tool.
> Handle mode 'm
And here's an update of the documentation:
2019-02-23 Bruno Haible
relocatable-prog: Update documentation.
* doc/relocatable-maint.texi (Supporting Relocation): Update to match
the recent changes.
diff --git a/doc/relocatable-maint.texi b/doc/relocatable-maint.texi
in
Paul Smith wrote:
> MacOS has @executable_path which is the same as $ORIGIN. See:
>
> https://wincent.com/wiki/%40executable_path%2C_%40load_path_and_%40rpath
Thanks for the pointer.
> Unfortunately on MacOS they have "applications" which are much more
> complicated and can have frameworks etc.
-changequote(,)dnl
case "$host_os" in
mingw*) is_noop=yes ;;
# For the platforms that support $ORIGIN, see
# <https://lekensteyn.nl/rpath.html>.
# glibc systems, Linux with musl libc: yes. Android: no.
- # Hurd: no
<http://lists.gnu.org/archiv
"wrapper"/"trampoline" executable on these platforms.
MacOS has @executable_path which is the same as $ORIGIN. See:
https://wincent.com/wiki/%40executable_path%2C_%40load_path_and_%40rpath
Unfortunately on MacOS they have "applications" which are much more
c
Paul Smith noted on gnu-prog-discuss that other systems than glibc have support
for $ORIGIN in rpath. This patch changes the 'relocatable-prog' module to
make use of this feature, thus removing the need for a "wrapper"/"trampoline"
executable on these platfo
Paul Eggert wrote on 2018-12-22:
> bore wrote:
> > What is causing this is
> > int _flags; \
> > int _file; \
> > on 32bit it needs to be
> > short _flags; \
> > short _file; \
>
> Thanks for the suggestion. Does the attached Gnulib patch fix the problem? I
> haven't installed it and can't easi
bore wrote:
What is causing this is
int _flags; \
int _file; \
on 32bit it needs to be
short _flags; \
short _file; \
Thanks for the suggestion. Does the attached Gnulib patch fix the problem? I
haven't installed it and can't easily test it.
>From 8f87a66104c1e270d3ada0eb2753ba835f7aa498 Mon
On Thu, Oct 18, 2018 at 7:56 AM Bruno Haible wrote:
>
> Paul Eggert wrote:
> > Thanks, those patches all look good to me.
>
> OK, pushed.
>
> There are still similar oldies (apollo, DGUX, NeXT) in getloadavg.c, that
> are still there for no good reason. But they are not introducing significant
> c
Paul Eggert wrote:
> Thanks, those patches all look good to me.
OK, pushed.
There are still similar oldies (apollo, DGUX, NeXT) in getloadavg.c, that
are still there for no good reason. But they are not introducing significant
complexity.
Bruno
Thanks, those patches all look good to me. Wow, it's been a while since
I last saw a Sony NEWS machine (and I actually used one, back in the
day).
untlist, getloadavg: Remove support for Dynix/ptx.
+ * lib/fsusage.c: Remove _SEQUENT_ case.
+ * m4/fsusage.m4 (gl_FILE_SYSTEM_USAGE): Update comments.
+ * lib/mountlist.c: Don't test for MNTTABNAME.
+ * m4/ls-mntd-fs.m4 (AC_FUNC_GETMNTENT): Don't test for libseq.
+ (gl_LIST_MOUNTED_FILE_S
Eric Blake wrote:
> > variable
> >gl_cv_func_wcwidth_works=no
> > at configure time.
>
> ... it is not a wise idea to codify
> that into libvirt's configure.ac (or any other project).
Yes, I agree.
> Rather, if libvirt is hitting test failures due solely to the difference
> of Unicode vers
On 08/31/2018 12:42 PM, Bruno Haible wrote:
Yes. This particular character (U+1F600) was added in Unicode 6.1 [1][2].
The iswprint() function is implemented in the libc, which is why you see
differences across platforms. After a new Unicode release is made, it
takes some time until the picks
Simon Kobyda wrote:
> It seems that functions gnulib's functions iswprint() and
> wcwidth() return different results on different platforms.
>
> Code on Fedora 28:
>
> wchar_t c = L'😀' ;
> if (iswprint(c))
> printf("Printable\n&quo
Simon Kobyda wrote:
Hello. It seems that functions gnulib's functions iswprint() and
wcwidth() return different results on different platforms.
Surely this is an issue of the platform's locales, not of Gnulib itself. Older
platforms won't recognize newer characters, and s
Hello. It seems that functions gnulib's functions iswprint() and
wcwidth() return different results on different platforms.
Code on Fedora 28:
wchar_t c = L'😀' ;
if (iswprint(c))
printf("Printable\n");
else
printf("Not printable\n&qu
I don't think most (if not all) reporters can provide the exact
version of bionic they are on, though you are welcome to ask on the
github issue I linked. Quite a few reporters were with 32-bit Android
7.1.1 I think.
I myself am with 64-bit Android 8.0.0 (Not an AOSP build but a Sony
stock ROM). I
Tom Yan wrote:
> http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blobdiff;f=lib/stdio-impl.h;h=393ef0cf58d013ec18cfcbb2ee120c4d1df7e028;hp=7a0ac4d50b70c5ad3d3b63d7f3274ba5d6df43a3;hb=e7fb52b3a5ddffe1bba848e4966159868b6951f0;hpb=be18f9170e1989b601a08aada31438cca87cffdd
>
> The definition of fp_
Tom Yan wrote:
Since the newly introduced definition of fp_ in stdio-impl.h is found
to be causing segfaults on quite some (if not most/all) 32-bit Android
builds, we patch it (hence 8.30"-1") to avoid the definition (on all
platforms).
With what patch, exactly?
apshot of it.
> I see this patch:
>
> https://github.com/termux/termux-packages/commit/86af1159d0d487368aab2494904e89b86f042fe2
>
> but it's not for 8.30-1. Also, the patch looks like it won't work on some
> Android platforms.
Since the newly introduced definition of
packages/commit/86af1159d0d487368aab2494904e89b86f042fe2
but it's not for 8.30-1. Also, the patch looks like it won't work on some
Android platforms.
Hi all,
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blobdiff;f=lib/stdio-impl.h;h=393ef0cf58d013ec18cfcbb2ee120c4d1df7e028;hp=7a0ac4d50b70c5ad3d3b63d7f3274ba5d6df43a3;hb=e7fb52b3a5ddffe1bba848e4966159868b6951f0;hpb=be18f9170e1989b601a08aada31438cca87cffdd
The definition of fp_ is causing s
I did this:
> 2017-09-26 Bruno Haible
>
> vma-iter: Improvements for Linux and BSD platforms.
> - Add support for DragonFly BSD.
> - Make it more reliable on Linux, GNU/kFreeBSD, FreeBSD, NetBSD.
> * lib/vma-iter.c (struct rofile, rof_open, rof_p
I pushed two more improvements of this module:
2017-09-26 Bruno Haible
vma-iter: Improvements for Linux and BSD platforms.
- Add support for DragonFly BSD.
- Make it more reliable on Linux, GNU/kFreeBSD, FreeBSD, NetBSD.
* lib/vma-iter.c (struct rofile
I'm improving the support of BSD platforms in the 'vma-iter' module
(used by GNU clisp).
2017-09-25 Bruno Haible
vma-iter: Improvements for BSD platforms.
- Add support for GNU/kFreeBSD.
- Make it work on FreeBSD and NetBSD even when /proc
..6568ff0 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2017-08-24 Paul Eggert
+
+ glob: fix typo that broke platforms lacking d_ino
+ This typo also hurt performance on GNU/Linux and similar hosts.
+ * lib/glob.c (D_INO_TO_RESULT): Fix typo (reversed ifdef)
+ in
1 - 100 of 236 matches
Mail list logo
