Re: svn commit: r268943 - in head: include lib/libc/stdlib
On Aug 3, 2014, at 9:39 AM, Pedro Giffuni wrote: > > Il giorno 03/ago/2014, alle ore 09:27, Warner Losh ha > scritto: > >> >> On Jul 21, 2014, at 12:51 PM, Pedro Giffuni wrote: >> >>> >>> Il giorno 21/lug/2014, alle ore 11:42, Bruce Simpson ha >>> scritto: >>> On 21/07/2014 16:22, Pedro F. Giffuni wrote: > ] > Log: > Add re-entrant versions of the hash functions based on the GNU api. > What, if anything, can be done about qsort_r() API incompatibility? >>> >>> qsort_r is non-standard and we did it first, plus we will want to stay >>> compatible with Apple :). >>> >>> I guess we could do some ugly parameter swapping in the case where >>> _GNU_SOURCE >>> is defined, but I won’t volunteer to do that. >> >> Are there any ABI considerations for the change? >> > > I would keep the qsort_r() ABI unchanged and add a GNU-compatible version > that is used only when _GNU_SOURCE (but not _BSD_SOURCE) is defined. > > This would already be pretty messy by itself because some portable code may > define _GNU_SOURCE but still may try to use the Apple/BSD interface under > another #ifdef. Perhaps it’s just better to leave our headers alone and let > the end-users do the wrapping. If there’s no ABI change, then I don’t care what we do about a non-standard API. However, once we’ve made an API public, standard or do, we have to support that ABI essentially forever when libc is involved. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r268943 - in head: include lib/libc/stdlib
Il giorno 03/ago/2014, alle ore 09:27, Warner Losh ha scritto: > > On Jul 21, 2014, at 12:51 PM, Pedro Giffuni wrote: > >> >> Il giorno 21/lug/2014, alle ore 11:42, Bruce Simpson ha >> scritto: >> >>> On 21/07/2014 16:22, Pedro F. Giffuni wrote: ] Log: Add re-entrant versions of the hash functions based on the GNU api. >>> What, if anything, can be done about qsort_r() API incompatibility? >> >> qsort_r is non-standard and we did it first, plus we will want to stay >> compatible with Apple :). >> >> I guess we could do some ugly parameter swapping in the case where >> _GNU_SOURCE >> is defined, but I won’t volunteer to do that. > > Are there any ABI considerations for the change? > I would keep the qsort_r() ABI unchanged and add a GNU-compatible version that is used only when _GNU_SOURCE (but not _BSD_SOURCE) is defined. This would already be pretty messy by itself because some portable code may define _GNU_SOURCE but still may try to use the Apple/BSD interface under another #ifdef. Perhaps it’s just better to leave our headers alone and let the end-users do the wrapping. Pedro. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r268943 - in head: include lib/libc/stdlib
On 03/08/2014 15:27, Warner Losh wrote: What, if anything, can be done about qsort_r() API incompatibility? qsort_r is non-standard and we did it first, plus we will want to stay compatible with Apple :). I guess we could do some ugly parameter swapping in the case where _GNU_SOURCE is defined, but I won’t volunteer to do that. Are there any ABI considerations for the change? I'm in agreement with Pedro here. Some form of compile-time checking is the best one can hope for in that situation, as it would be difficult to "ret-con" the qsort_r() ABI itself. The glibc implementation swaps two pointers in its signature. One of those points to executable code. The last time this caused problems for me was when testing the new CScope indexing backend by Elad Lahav on BSD/Mac. He had developed on Linux, however the quick fix was to fall back to using non-reentrant qsort(). ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r268943 - in head: include lib/libc/stdlib
On Jul 21, 2014, at 12:51 PM, Pedro Giffuni wrote: > > Il giorno 21/lug/2014, alle ore 11:42, Bruce Simpson ha > scritto: > >> On 21/07/2014 16:22, Pedro F. Giffuni wrote: >>> ] >>> Log: >>> Add re-entrant versions of the hash functions based on the GNU api. >>> >> What, if anything, can be done about qsort_r() API incompatibility? > > qsort_r is non-standard and we did it first, plus we will want to stay > compatible with Apple :). > > I guess we could do some ugly parameter swapping in the case where _GNU_SOURCE > is defined, but I won’t volunteer to do that. Are there any ABI considerations for the change? Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r268943 - in head: include lib/libc/stdlib
Il giorno 21/lug/2014, alle ore 11:42, Bruce Simpson ha scritto: > On 21/07/2014 16:22, Pedro F. Giffuni wrote: >> ] >> Log: >> Add re-entrant versions of the hash functions based on the GNU api. >> > What, if anything, can be done about qsort_r() API incompatibility? qsort_r is non-standard and we did it first, plus we will want to stay compatible with Apple :). I guess we could do some ugly parameter swapping in the case where _GNU_SOURCE is defined, but I won’t volunteer to do that. Pedro. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r268943 - in head: include lib/libc/stdlib
On 21/07/2014 16:22, Pedro F. Giffuni wrote: ] Log: Add re-entrant versions of the hash functions based on the GNU api. What, if anything, can be done about qsort_r() API incompatibility? ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r268943 - in head: include lib/libc/stdlib
Author: pfg
Date: Mon Jul 21 15:22:48 2014
New Revision: 268943
URL: http://svnweb.freebsd.org/changeset/base/268943
Log:
Add re-entrant versions of the hash functions based on the GNU api.
While testing this I found a conformance issue in hdestroy()
that will be fixed in a subsequent commit.
Obtained from:NetBSD (hcreate.c, CVS Rev. 1.7)
Modified:
head/include/search.h
head/lib/libc/stdlib/Makefile.inc
head/lib/libc/stdlib/Symbol.map
head/lib/libc/stdlib/hcreate.3
head/lib/libc/stdlib/hcreate.c
Modified: head/include/search.h
==
--- head/include/search.h Mon Jul 21 14:36:35 2014(r268942)
+++ head/include/search.h Mon Jul 21 15:22:48 2014(r268943)
@@ -1,8 +1,8 @@
/*-
- * Written by J.T. Conklin
+ * Written by J.T. Conklin
* Public domain.
*
- * $NetBSD: search.h,v 1.12 1999/02/22 10:34:28 christos Exp $
+ * $NetBSD: search.h,v 1.16 2005/02/03 04:39:32 perry Exp $
* $FreeBSD$
*/
@@ -45,6 +45,15 @@ struct que_elem {
};
#endif
+#if __BSD_VISIBLE
+struct _ENTRY;
+struct hsearch_data {
+ struct _ENTRY *table;
+ size_t size;
+ size_t filled;
+};
+#endif
+
__BEGIN_DECLS
int hcreate(size_t);
voidhdestroy(void);
@@ -61,6 +70,13 @@ void *tfind(const void *, void * const *
int (*)(const void *, const void *));
void *tsearch(const void *, void **, int (*)(const void *, const void *));
voidtwalk(const void *, void (*)(const void *, VISIT, int));
+
+#if __BSD_VISIBLE
+int hcreate_r(size_t, struct hsearch_data *);
+voidhdestroy_r(struct hsearch_data *);
+int hsearch_r(ENTRY, ACTION, ENTRY **, struct hsearch_data *);
+#endif
+
__END_DECLS
#endif /* !_SEARCH_H_ */
Modified: head/lib/libc/stdlib/Makefile.inc
==
--- head/lib/libc/stdlib/Makefile.inc Mon Jul 21 14:36:35 2014
(r268942)
+++ head/lib/libc/stdlib/Makefile.inc Mon Jul 21 15:22:48 2014
(r268943)
@@ -35,6 +35,7 @@ MLINKS+=exit.3 _Exit.3
MLINKS+=getenv.3 putenv.3 getenv.3 setenv.3 getenv.3 unsetenv.3
MLINKS+=getopt_long.3 getopt_long_only.3
MLINKS+=hcreate.3 hdestroy.3 hcreate.3 hsearch.3
+MLINKS+=hcreate.3 hcreate_r.3 hcreate.3 hdestroy_r.3 hcreate.3 hsearch_r.3
MLINKS+=insque.3 remque.3
MLINKS+=lsearch.3 lfind.3
MLINKS+=ptsname.3 grantpt.3 ptsname.3 unlockpt.3
Modified: head/lib/libc/stdlib/Symbol.map
==
--- head/lib/libc/stdlib/Symbol.map Mon Jul 21 14:36:35 2014
(r268942)
+++ head/lib/libc/stdlib/Symbol.map Mon Jul 21 15:22:48 2014
(r268943)
@@ -109,6 +109,9 @@ FBSD_1.4 {
heapsort_b;
mergesort_b;
qsort_b;
+ hcreate_r;
+ hdestroy_r;
+ hsearch_r;
};
FBSDprivate_1.0 {
Modified: head/lib/libc/stdlib/hcreate.3
==
--- head/lib/libc/stdlib/hcreate.3 Mon Jul 21 14:36:35 2014
(r268942)
+++ head/lib/libc/stdlib/hcreate.3 Mon Jul 21 15:22:48 2014
(r268943)
@@ -28,11 +28,16 @@
.\"
.\" $FreeBSD$
.\"
-.Dd July 6, 2008
+.Dd July 21, 2014
.Dt HCREATE 3
.Os
.Sh NAME
-.Nm hcreate , hdestroy , hsearch
+.Nm hcreate ,
+.Nm hcreate_r ,
+.Nm hdestroy ,
+.Nm hdestroy_r ,
+.Nm hsearch ,
+.Nm hsearch_r
.Nd manage hash search table
.Sh LIBRARY
.Lb libc
@@ -40,16 +45,25 @@
.In search.h
.Ft int
.Fn hcreate "size_t nel"
+.Ft int
+.Fn hcreate_r "size_t nel" "struct hsearch_data *table"
+.Ft void
+.Fn hdestroy "void"
.Ft void
-.Fn hdestroy void
+.Fn hdestroy_r "struct hsearch_data *table"
.Ft ENTRY *
.Fn hsearch "ENTRY item" "ACTION action"
+.Ft int
+.Fn hsearch_r "ENTRY item" "ACTION action" "ENTRY ** itemp" "struct
hsearch_data *table"
.Sh DESCRIPTION
The
.Fn hcreate ,
+.Fn hcreate_r ,
.Fn hdestroy ,
+.Fn hdestroy_r
+.Fn hsearch ,
and
-.Fn hsearch
+.Fn hsearch_r
functions manage hash search tables.
.Pp
The
@@ -90,7 +104,7 @@ argument is a structure of type
.Vt ENTRY
(defined in the
.In search.h
-header) containing two pointers:
+header) that contains two pointers:
.Fa item.key
points to the comparison key (a
.Vt "char *" ) ,
@@ -136,21 +150,50 @@ is
and
.Fn hdestroy
is called.
+.Pp
+The
+.Fn hcreate_r ,
+.Fn hdestroy_r ,
+and
+.Fn hsearch_r
+functions are re-entrant versions of the above functions that can
+operate on a table supplied by the user.
+The
+.Fn hsearch_r
+function returns
+.Dv 0
+if the action is
+.Dv ENTER
+and the element cannot be created,
+.Dv 1
+otherwise.
+If the element exists or can be created, it will be placed in
+.Fa itemp ,
+otherwise
+.Fa itemp
+will be set to
+.Dv NULL .
.Sh RETURN VALUES
The
.Fn hcreate
-function returns 0 if the table creation failed and the global variable
+and
+.Fn hcreate_r
+functions return 0 if the table creation failed and the global v
