Date: Fri, 18 Jul 2014 00:15:30 -0500 From: Pedro Giffuni <pfg@freebsd.org> To: Bruce Evans <brde@optusnet.com.au> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r268826 - head/include Message-ID: <DBEE3412-7772-4FB7-B9BE-66CEEB649A51@freebsd.org> In-Reply-To: <20140718131924.O1045@besplex.bde.org> References: <201407180249.s6I2nfiF062643@svn.freebsd.org> <20140718131924.O1045@besplex.bde.org>
index | next in thread | previous in thread | raw e-mail
Hi; Il giorno 17/lug/2014, alle ore 23:35, Bruce Evans <brde@optusnet.com.au> ha scritto: > On Fri, 18 Jul 2014, Pedro F. Giffuni wrote: > >> Log: >> Minor sorting to match the NetBSD header > > Unsorting. > > 2 other style bugs (extra blank lines). > >> MFC after: 3 days >> Obtained from: NetBSD > > Please no. OK, I will revert. > >> Modified: >> head/include/search.h >> >> Modified: head/include/search.h >> ============================================================================== >> --- head/include/search.h Fri Jul 18 01:35:20 2014 (r268825) >> +++ head/include/search.h Fri Jul 18 02:49:41 2014 (r268826) >> @@ -1,8 +1,8 @@ >> /*- >> - * Written by J.T. Conklin <jtc@netbsd.org> >> + * Written by J.T. Conklin <jtc@NetBSD.org> >> * Public domain. >> * >> - * $NetBSD: search.h,v 1.12 1999/02/22 10:34:28 christos Exp $ >> + * $NetBSD: search.h,v 1.18 2005/07/06 15:47:15 drochner Exp $ >> * $FreeBSD$ >> */ >> >> @@ -49,12 +49,14 @@ __BEGIN_DECLS >> int hcreate(size_t); >> void hdestroy(void); >> ENTRY *hsearch(ENTRY, ACTION); >> -void insque(void *, void *); >> + >> void *lfind(const void *, const void *, size_t *, size_t, >> int (*)(const void *, const void *)); >> void *lsearch(const void *, void *, size_t *, size_t, >> int (*)(const void *, const void *)); >> +void insque(void *, void *); >> void remque(void *); >> + >> void *tdelete(const void * __restrict, void ** __restrict, >> int (*)(const void *, const void *)); >> void *tfind(const void *, void * const *, > > This does less than undo the style fixes made in FreeBSD, mostly in > 2002 (it doesn't undo removing __P(()) or the indentation fix for > twalk). > NetBSD also removed __P(()) on this header. I noticed those changes and also the lack of bsearch. > The churn for unsorting insque() and the extra blank lines was already > very complicated and ugly: > - originally (in 4.4BSD-Lite), lfind(), lsearch(), insque() and remque() were > compatibility cruft in libcompat. This was reflected by intentionally > not declaring them in any header. > - then in 2000, search.h was imported from NetBSD. The deprecation of the > functions was broken by declaring them there. It was only hinted at by > unsorting them into a subsection in the middle of the file, with insque() > unsorted internally exactly as above, and extra blank lines to delimit > the subsection, exactly as above. The current commit is a not quite > complete regression to this version. > - then in rev.1.2 in 2000, the subsection was commented out and marked > as depricated (sic). The style of the rest of the commit was as good > as its spelling. It also commented out bsearch(). The "depricated" > comment at the beginning of the section made the extra blank lines > non-extra, but the commit also removed the leading blank line so > the subsection looked like it was attached to the previous one. > - then in rev.1.3 in 2000, after I complained about 1.2, all the style > bugs were fixed by removing all the commented out sections and the > remaining extra blank line. > - then in rev.1.8 in 2002, a comment was added about insque(), lsearch() > and remque() being missing. lfind() was missing in the comment. See > below about where they were. > - then in rev.1.9 in 2002, insque() and remque() were moved back here to > go with moving them from libcompat to libc. They were correctly > sorted and not placed in an subsection. > - then in rev.1.10 in 2002, lfind() and lsearch() were moved back here. > There was no unsorting to fix for them, and they were not placed in > a subsection. > > bsearch() is in C90. C90 of course doesn't have <search.h>, and it put > bsearch() in <stdlib.h>. 4.4BSD also doesn't have <search.h>, and > declared bsearch() in the correct place. This was broken in FreeBSD > in 2000 by importing the "original" version of <search.h> from NetBSD. > The bug (extra misplaced declaration of bsearch()) only lived for 6 > days. > > The other 4 churned functions were standardized by POSIX in 2001, so > importing them and search.h was just in time to prepare for this version > of POSIX and removing them in search.h within 6 days of the import was > just in time to break this. FreeBSD didn't declare the functions in > any standard header before search.h was imported. They were intentionally > left out and had been dead for 10-15 years before POSIX brought them > back. FreeBSD just had rotting bits in several places. There was a > private search.h in lib/libc/db/hash. This header came complete with > a comment about insque being depricated (sic), but didn't declare it. > ed/ed.h used to have a home made version of insque(), and ed/README > still has rotted bits documenting the defunct option NEED_INSQUE for > configuring this. > > Since the other 4 churned functions are now standard, they shouldn't > be unsorted in a special unsorted undocumented subsection. They are > precisely as standard as all of the other functions in search.h. > search.h doesn't have any extensions, and the prototypes in it are > exactly as in POSIX.1-2001, except for minor formatting differences > and now the unsorting of insque() and the extra blank lines. > The reason for re-sorting was that I want to bring the reentrant versions hcreate_r(), hcdestroy_r() and hsearch_r() (GNU extensions) from NetBSD. NetBSD also re-licensed their (hsearch.c) implementation under 2-clause BSD license after adding the reentrant versions. I will leave the reentrant functions properly #ifdef’ed at the end of the file. and I will post the code for review when it’s ready. Pedro.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DBEE3412-7772-4FB7-B9BE-66CEEB649A51>