Pádraig Brady wrote:
> On 02/07/10 20:17, Jim Meyering wrote:
>> Thanks again for the report.
>> However, while I was able to reproduce it (on Paul's system)
>> and debug it, it appears to be due to a miscompilation of di-set.o
>> when using a private copy of gcc-4.5.0. When I recompiled
>> that o
On 02/07/10 20:17, Jim Meyering wrote:
> Thanks again for the report.
> However, while I was able to reproduce it (on Paul's system)
> and debug it, it appears to be due to a miscompilation of di-set.o
> when using a private copy of gcc-4.5.0. When I recompiled
> that one file with gcc-Ubuntu 4.4.
Jim Meyering wrote:
> > OK to commit?
>
> Yes, that looks fine.
Actually MacOS X and OpenBSD now also support the POSIX API (statvfs function).
I've adjusted the comments as below and pushed it.
--- m4/fsusage.m4 2010-07-04 23:44:29.0 +0200
+++ m4/fsusage.m42010-07-04 23:41:11.
Bruno Haible wrote:
> Hi Jim,
>
>> > Upon inspection, it appears that the fu_cv_sys_stat_statfs2_bsize
>> > test in m4/fsusage.m4 (labelled "AIX") would succeed on
>> > glibc, MacOS X, FreeBSD, NetBSD, OpenBSD, AIX, HP-UX, Solaris, Cygwin
>> > ...
>> > without a clear overview of which platform e
Hi Jim,
> > Upon inspection, it appears that the fu_cv_sys_stat_statfs2_bsize
> > test in m4/fsusage.m4 (labelled "AIX") would succeed on
> > glibc, MacOS X, FreeBSD, NetBSD, OpenBSD, AIX, HP-UX, Solaris, Cygwin
> > ...
> > without a clear overview of which platform ends up using which code,
> >
Hi,
I've released a new stable snapshot. See attached NEWS.stable for details.
Feedback welcome.
Tarball: http://erislabs.net/ianb/projects/gnulib/gnulib-20100704-stable.tar.gz
Gitweb: http://erislabs.net/gitweb?p=gnulib.git;a=shortlog;h=refs/heads/stable
Git: git://erislabs.net/gnulib.gi
Hello Martin,
Martin Lambers wrote:
> It seems that the AC_LIB_FROMPACKAGE macro from the havelib module can
> be used at most twice for a given package name. The following works:
>
> AC_INIT([foobar], [0.1], [t...@example.com])
> AC_CONFIG_MACRO_DIR([.])
> AC_LIB_FROMPACKAGE([a], [libfoo])
> AC_
Hi José,
> I think that I may be mixing two different things:
> set membership and searching in the contents of the set. I will try
> to clarify myself:
>
> - A membership function would get an element and would return a
> boolean indicating whether the element is contained in the set. A
> s
Jim Meyering wrote:
> I think the goal of this function is to return the single (first?)
> KEY-matching entry from the set ...
> ...
> Think of set of composite values (a struct), of which
> one serves as a key. You may want to query whether a
> dummy { key, x, y, z } is in the set, solely to find
> An unordered set is effectively a mapping between a key and a boolean
> (membership) so I am not sure what would be the benefit of returning
> something like 'gl_set_node_t' instead of the boolean directly. In
> case we want to change the membership status for some key then we
Jose E. Marchesi wrote:
>
> >gl_set_search O(n) O(1)
> >
> >Here the search method returns a void *, with value (void*)-1
> >denoting "not found". Hmm, or should the search method better
> >take a 'bool *' argument???
> >
>
>gl_set_search O(n) O(1)
>
>Here the search method returns a void *, with value (void*)-1
>denoting "not found". Hmm, or should the search method better
>take a 'bool *' argument???
>
> If 'gl_set_search' is merely t
I looked at allowing NULL key values in hash.c,
but decided not to pursue that right now. The change below
reinstates the NULL check in hash_insert0 that I removed
a few days ago.
If you have to insert a NULL pointer, the hash module API has
a fundamental limitation. For example, hash_lookup ret
Jose E. Marchesi wrote:
>gl_set_search O(n) O(1)
>
>Here the search method returns a void *, with value (void*)-1
>denoting "not found". Hmm, or should the search method better
>take a 'bool *' argument???
>
> If 'gl_set_search' is merely testing t
14 matches
Mail list logo
