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
Fix a gcc warning.
* lib/write.c (rpl_write): Cast result of _get_osfhandle.
--- lib/write.c.orig2009-08-11 01:01:56.0
On Mon, Aug 10, 2009 at 6:26 PM, Bruno Haible 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 build/gnulib/ t
Sam Steingold wrote:
> > It would be worth trying to not --avoid=unistd in the modules
> > subdirectories.
> > This should lead to a different being generated for the module
> > subdirectory than for the clisp core, but a more complete one.
> >
> > More generally, you want to use --avoid for modu
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 fi
On Sat, Aug 8, 2009 at 3:14 AM, Bruno Haible wrote:
> It would be worth trying to not --avoid=unistd in the modules subdirectories.
> This should lead to a different being generated for the module
> subdirectory than for the clisp core, but a more complete one.
>
> More generally, you want to use
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] http://lists
Paolo Bonzini wrote:
> No, gethostname does not require sockets &c, it just requires sys/socket.h.
And gethostname() does not open user-visible sockets.
> IIRC, something like this:
>
> diff --git a/lib/unistd.in.h b/lib/unistd.in.h
> index 93edb48..733c8b6 100644
> --- a/lib/unistd.in.h
> +++ b
Hello Sergey,
* Sergey Poznyakoff wrote on Sun, Aug 09, 2009 at 11:25:51PM CEST:
> The proposed patch considerably speed-ups the exclude module
> for large exclusion lists of non-wildcard patterns. Ok to push?
> --- a/lib/exclude.c
> +++ b/lib/exclude.c
> +/* Return true if str is a fnmatch patt
On Mon, Aug 10, 2009 at 3:29 PM, Paolo Bonzini 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, una
strftime on linux supports %F and %T which are, I guess, extensions.
any plans to support it in gnulib/strftime?
Paolo Bonzini 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 projec
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
dependenc
On Mon, Aug 10, 2009 at 2:22 PM, Sam Steingold 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.
... and when
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 dependen
On Sat, Aug 8, 2009 at 3:14 AM, Bruno Haible 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':
>> /cygdrive/c/sds/dev/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
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 t
Bruno Haible 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 constants i
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
On Mon, Aug 10, 2009 at 10:12 AM, Simon Josefsson wrote:
> Sam Steingold 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 gnulib, it wants to compil
Bruno Haible 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
>
>
Sam Steingold writes:
> On Mon, Aug 10, 2009 at 6:28 AM, Simon Josefsson wrote:
>> Bruno Haible 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
On Mon, Aug 10, 2009 at 6:28 AM, Simon Josefsson wrote:
> Bruno Haible 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
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
Avoid collision between gnulib wrapper and libintl wrap
Bruno Haible 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 issue with compili
Bruno Haible 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' -> '^a.b$'
>
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 ca
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.
28 matches
Mail list logo
