Bruno Haible wrote:
Jim Meyering wrote:
Ok to push this fix?
+* tests/test-select-stdin.c: Include string.h for decl of memset,
No. test-select-stdin.c does not use memset(), therefore there is no reason
for this file to include string.h.
The memset() call that the warnings refers to
Hi Bruno,
'is_fnmatch_pattern' is probably a misnomer, because its argument is
by definition already an fnmatch pattern. What the function is testing is
whether it contains wildcard characters
Yes, indeed.
Btw, this function does not handle multiple adjacent backslashes correctly,
i.e.
Sergey Poznyakoff wrote:
By the way, I am also experimenting with the idea of re-implementing
the exclude module using DFA, i.e. regarding the entire exclude list
as a set of regular language definitions and creating a DFA for each
of them (it is a *set* of definitions, because its parts can
Bruno Haible br...@clisp.org ha escrit:
Why does it not fit into two regexes / DFAs?
Yes, it would, provided that we translate fnmatch patterns to regexps.
EXCLUDE_WILDCARDS on: 'a?b*' - 'a.b.*'
EXCLUDE_WILDCARDS off: 'a?b*' - 'a[?]b[*]'
EXCLUDE_ANCHORED on: 'a?b' -
Bruno Haible br...@clisp.org writes:
Should the 'regex' module (and possibly other modules which require C
syntax) depend on the 'no-c++' module? We can open a poll on it.
I don't understand the rationale for the no-c++ module, let alone making
any other modules depend on it.
What is the
This fixes a collision between the gnulib wrapper for printf (called
'__printf__') and the libintl wrapper for printf (also called
'__printf__'). Seen when compiling gettext with --disable-shared on
mingw.
2009-08-10 Bruno Haible br...@clisp.org
Avoid collision between gnulib wrapper
On Mon, Aug 10, 2009 at 6:28 AM, Simon Josefssonsi...@josefsson.org wrote:
Bruno Haible br...@clisp.org writes:
Should the 'regex' module (and possibly other modules which require C
syntax) depend on the 'no-c++' module? We can open a poll on it.
I don't understand the rationale for the
Sam Steingold s...@gnu.org writes:
On Mon, Aug 10, 2009 at 6:28 AM, Simon Josefssonsi...@josefsson.org wrote:
Bruno Haible br...@clisp.org writes:
Should the 'regex' module (and possibly other modules which require C
syntax) depend on the 'no-c++' module? We can open a poll on it.
I don't
Bruno Haible br...@clisp.org writes:
Simon Josefsson wrote:
Right, it seems clear that gnulib should define HOST_NAME_MAX on more
systems.
I note that a Solaris 10 I have access to defines _POSIX_HOST_NAME_MAX:
/usr/include/limits.h:#define _POSIX_HOST_NAME_MAX255
On Mon, Aug 10, 2009 at 10:12 AM, Simon Josefssonsi...@josefsson.org wrote:
Sam Steingold s...@gnu.org writes:
Some packages are compilable with both C (production) and C++ (extra
compilation time type checking and run-time verification for
debugging).
when such a package uses code from
Simon Josefsson wrote:
Is the maximum string ever returned by gethostname bounded by
MAXHOSTNAMELEN?
I expect so.
It seems clear that FreeBSD isn't POSIX compliant here since
HOST_NAME_MAX needs to be provided, as far as I can tell.
So, FreeBSD is POSIX compliant. See [1]: HOST_NAME_MAX is
Bruno Haible br...@clisp.org writes:
It seems clear that FreeBSD isn't POSIX compliant here since
HOST_NAME_MAX needs to be provided, as far as I can tell.
So, FreeBSD is POSIX compliant. See [1]: HOST_NAME_MAX is inside a section
that begins with:
A definition of one of the symbolic
Is there a wide class of projects or operating systems that recommends
or suggests use of CC=c++ that I've missed? I'm trying to understand
the origins of the CC=c++ notion. Learning that may help me understand
the bigger picture.
For example, when a project is considering switching from C
Simon Josefsson wrote:
Then I'm less sure that it makes sense for
gnulib's limit.h to define HOST_NAME_MAX -- programs written against
POSIX should not assume that symbol exists.
On the other hand, the support of POSIX for unspecified maximum host
name lengths is weak: You see in [1] that
-
On Sat, Aug 8, 2009 at 3:14 AM, Bruno Haiblebr...@clisp.org wrote:
Sam Steingold wrote:
In file included from
/cygdrive/c/sds/dev/current/modules/syscalls/gllib/gethostname.c:83:
/cygdrive/c/sds/dev/current/modules/syscalls/gllib/w32sock.h: In function
`set_winsock_errno':
What does this mean?
I did not request the close module, and it is not clear why I should.
(in fact, I don't see why pulling uname should change the semantics of close.
yes, uname requires gethostname, which requires sockets c, so I see the
dependency chain, but I think what I see is a
On Mon, Aug 10, 2009 at 2:22 PM, Sam Steingolds...@gnu.org wrote:
I followed your instructions, so now I have unistd.h both in the above
and in build/gllib/unistd.h
the former comes first on the gcc -I list, but, apparently, #include
next discards it and only the latter is actually used.
...
On 08/10/2009 09:02 PM, Sam Steingold wrote:
What does this mean?
I did not request the close module, and it is not clear why I should.
(in fact, I don't see why pulling uname should change the semantics of
close.
yes, uname requires gethostname, which requires sockets c, so I see the
Paolo Bonzini bonz...@gnu.org writes:
Is there a wide class of projects or operating systems that recommends
or suggests use of CC=c++ that I've missed? I'm trying to understand
the origins of the CC=c++ notion. Learning that may help me understand
the bigger picture.
For example, when a
strftime on linux supports %F and %T which are, I guess, extensions.
any plans to support it in gnulib/strftime?
On Mon, Aug 10, 2009 at 3:29 PM, Paolo Bonzinibonz...@gnu.org wrote:
On 08/10/2009 09:02 PM, Sam Steingold wrote:
What does this mean?
I did not request the close module, and it is not clear why I should.
(in fact, I don't see why pulling uname should change the semantics of
close.
yes,
Sam Steingold wrote:
strftime on linux supports %F and %T which are, I guess, extensions.
any plans to support it in gnulib/strftime?
Good point. Nothing happened after this discussion a year ago: [1] [2].
[1] http://lists.gnu.org/archive/html/bug-gnulib/2008-08/msg00223.html
[2]
On Sat, Aug 8, 2009 at 3:14 AM, Bruno Haiblebr...@clisp.org wrote:
It would be worth trying to not --avoid=unistd in the modules subdirectories.
This should lead to a different unistd.h being generated for the module
subdirectory than for the clisp core, but a more complete one.
More
In some autoconf macros, we tried to optimize invocations to AC_LIBOBJ.
The idiom, such as found in strstr.m4, is that the default value of
REPLACE_STRSTR is 0, and when REPLACE_STRSTR is 1, we need to organize
to compile strstr.c. Some clever optimization was to execute the
AC_LIBOBJ only the
Sam Steingold wrote:
It would be worth trying to not --avoid=unistd in the modules
subdirectories.
This should lead to a different unistd.h being generated for the module
subdirectory than for the clisp core, but a more complete one.
More generally, you want to use --avoid for modules
On Mon, Aug 10, 2009 at 6:26 PM, Bruno Haiblebr...@clisp.org wrote:
Sam Steingold wrote:
the bottom line is:
if I add -I build/gnulib/ to module CFLAGS, then include_next will
make build/gnulib/unistd.h supersede build/syscalls/gnulib/unistd.h,
which is no good.
if I do NOT add -I
Seen on mingw:
write.c:49: warning: passing arg 1 of `GetFileType' makes pointer from integer
without a cast
This fixes it.
2009-08-10 Bruno Haible br...@clisp.org
Fix a gcc warning.
* lib/write.c (rpl_write): Cast result of _get_osfhandle.
--- lib/write.c.orig
27 matches
Mail list logo
