Hi Paul,
> which doesn’t work when
> compiled with stricter C17-and-earlier compilers. The feature is
> using ‘#define f(a, ...) b’ and calling ‘f’ with only one arg.
1) Comparing ISO C 17 § 6.10.3.(12) vs. ISO C 23 § 6.10.5.(12):
The C 17 text also has the "(if any)" part; so that means that
in
Typo. I meant:
we would have one macro
_GL_FUNCDECL_SYS (func, rettype, parameters, attributes);
and invoke it with 4 arguments always, e.g.
_GL_FUNCDECL_SYS (getprogname, const char *, (void),);
_GL_FUNCDECL_SYS (getprogname, const char *, (void), _GL_ATTRIBUTE_PURE);
Bruno
To fix this:
> 2) The CI reports a compilation error on many platforms:
>
> In file included from ./uchar.h:61,
> from ../../gllib/btoc32.c:23:
> ./wchar.h:815:61: error: macro "_GL_FUNCDECL_RPL" passed 4 arguments, but
> takes just 3
> 815 | _GL_FUNCDECL_RPL (btowc, wint_t, (
And another compilation error from yesterday's patch:
In file included from /usr/i686-w64-mingw32/sys-root/mingw/include/uchar.h:28,
from ./uchar.h:45,
from ../../gllib/btoc32.c:23:
./wchar.h:843:62: error: macro "_GL_FUNCDECL_RPL" passed 4 arguments, but takes
j
LIBCx, which is a kLIBC extension library, provides spawn2() to support
this feature. If LIBCx is available, then support a directory argument
using spawn2() of LIBCx.
* lib/spawn-pipe.c (create_pipe) [kLIBC]: Use spawn2() of LIBCx to support
a directory argument if available.
* m4/spawn-pipe.m4 (
LIBCx is the kLIBC extension library which provides some enhanced
features to OS/2 kLIBC.
It provides its own wait(), waitid() and waitpid() to support its
spawn2().
Use them if possible.
* lib/sys_wait.in.h (rpl_wait, rpl_waitid, rpl_waitpid): New
declaration.
* lib/wait.c: New file.
* lib/wait
Hi/2.
These patches allow to use a directory argument of create_pipe() on
OS/2 kLIBC.
Review, please...
[PATCH 1/2] wait, waitid, waitpid: Use ones from LIBCx on OS/2 kLIBC
[PATCH 2/2] spawn-pipe: Support a directory argument of create_pipe()
Hi,
KO Myung-Hun wrote:
> These patches allow to use a directory argument of create_pipe() on
> OS/2 kLIBC.
Four things I don't understand:
- You still don't have posix_spawn support for this platform?
With posix_spawn working, no extra code would be needed in spawn-pipe.c.
Is os2-spawn.[hc]
Hi/2.
Bruno Haible wrote:
> Hi,
>
> KO Myung-Hun wrote:
>> These patches allow to use a directory argument of create_pipe() on
>> OS/2 kLIBC.
>
> Four things I don't understand:
>
> - You still don't have posix_spawn support for this platform?
> With posix_spawn working, no extra code would b
KO Myung-Hun wrote:
> > - What is the point of adding wait() and waitid() in patch 1? Nothing in
> > spawn-pipe.c nor wait-process.c uses wait(), waitid().
> >
>
> spawn-pipe.c returns a pid of a child process. If it passes to wait()
> and/or waitid(), wait() and waitid() of libcx should be use
On 2024-09-16 00:16, Bruno Haible wrote:
How about, instead of defining two macros
_GL_FUNCDECL_SYS (func, rettype, parameters);
_GL_FUNCATTR_SYS (func, rettype, parameters, attributes);
we would have one macro
_GL_FUNCDECL_SYS (func, rettype, parameters, attributes);
and invoke it
I discovered this unnecessary dependency when debugging
GNU Patch.
* lib/parse-datetime.y:
(populate_local_time_zone_table) [!HAVE_STRUCT_TM_TM_ZONE]:
(debug_strfdatetime): Use strftime not nstrftime,
as we don’t need nstrftime’s extensions or bug fixes.
* modules/parse-datetime (Depends-on): Remov
Oops, I messed up and committed the wrong file. I fixed that by
installing the attached fixup. Sorry about that.
From e3a81ab6e1201eb40a9f861c75162b41af148c10 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Mon, 16 Sep 2024 11:19:17 -0700
Subject: [PATCH] Fix typo in previous patch
---
lib/p
Paul Eggert wrote:
> Thanks, that sounds nicer. I did that.
Thanks a lot!
> My earlier patch had been
> assuming we couldn't use that C99 feature; I also documented that we're
> assuming C99 empty macro args by installing the attached additional patch.
Nice. My knowledge comes from the fact th
The new unilbrk tests produce warnings:
* with gcc -Wall:
../../gltests/unilbrk/test-uc-possible-linebreaks.c:151:69: warning: suggest
parentheses around '&&' within '||' [-Wparentheses]
../../gltests/unilbrk/test-uc-possible-linebreaks.c:153:72: warning: suggest
parentheses around '&&' within
Compiling a gnulib testdir with "clang -Wall", I see these warnings:
../../gllib/unictype/categ_of.h:236:47: warning: implicit conversion from 'int'
to 'short' changes value from 32768 to -32768 [-Wconstant-conversion]
../../gllib/unictype/categ_of.h:240:54: warning: implicit conversion from 'int
* m4/fflush.m4 (gl_FUNC_FFLUSH_STDIN): Guess no on NetBSD and
OpenBSD; they document fflush to fail unless the stream is open
for writing.
---
ChangeLog | 7 +++
doc/posix-functions/fflush.texi | 3 +++
m4/fflush.m4| 11 ++-
3 files changed,
On AIX 7.1, I'm seeing this test failure:
FAIL: test-faccessat
../../gltests/test-faccessat.c:58: assertion 'errno == ENOTDIR' failed
FAIL test-faccessat (exit status: 134)
In lines 58, 60, 62, the errno value is EACCES instead of the ENOTDIR
that we expect.
This patch exte
g++ version 4.3.6 and older, when encoutering a constant literal
0x
gives an error
error: integer constant is too large for ‘long’ type
For example, on Fedora 1 with g++ 3.3.2, we get this error:
g++ -DHAVE_CONFIG_H -DEXEEXT=\"\" -DEXEEXT=\"\" -I. -I..
-DGNULIB_STRICT_CHECKI
On Solaris 10, with the Sun Studio 11 'CC' (a.k.a. SunPRO C++),
I see this compilation error:
CC -O -DHAVE_CONFIG_H -DEXEEXT=\"\" -DEXEEXT=\"\" -I. -I../../gltests -I..
-DGNULIB_STRICT_CHECKING=1 -DIN_GNULIB_TESTS=1 -I. -I../../gltests -I..
-I../../gltests/.. -I../gllib -I../../gltests/../
On this platform, declares utimens and lutimens and the
C library defines them, so we needn’t (and shouldn’t).
Problem reported privately by Thomas Klausner.
* lib/utimens.c (utimens) [HAVE_UTIMENS]: Don’t define.
(lutimens) [HAVE_LUTIMENS]: Don’t define.
* lib/utimens.h [HAVE_UTIMENS || HAVE_LUTI
21 matches
Mail list logo
