From owner-freebsd-audit Sun Oct 7 10:36:59 2001 Delivered-To: freebsd-audit@freebsd.org Received: from coffee.q9media.com (coffee.q9media.com [216.94.229.19]) by hub.freebsd.org (Postfix) with ESMTP id 4045D37B403; Sun, 7 Oct 2001 10:36:56 -0700 (PDT) Received: (from mike@localhost) by coffee.q9media.com (8.11.6/8.11.6) id f97HbHq43774; Sun, 7 Oct 2001 13:37:17 -0400 (EDT) (envelope-from mike) Date: Sun, 7 Oct 2001 13:37:16 -0400 From: Mike Barcroft To: "Andrey A. Chernov" Cc: Peter Pentchev , freebsd-net@FreeBSD.ORG, freebsd-audit@FreeBSD.ORG Subject: Re: [CFR] whois(1) out-of-bound access patch Message-ID: <20011007133716.C37270@coffee.q9media.com> References: <20011004121640.C1959@ringworld.oblivion.bg> <20011004132801.A64960@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011004132801.A64960@nagual.pp.ru>; from ache@nagual.pp.ru on Thu, Oct 04, 2001 at 01:28:02PM +0400 Organization: The FreeBSD Project Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Andrey A. Chernov writes: > On Thu, Oct 04, 2001 at 12:16:40 +0300, Peter Pentchev wrote: > > + if ((len == 0) || !isspace(buf[len - 1])) { > > Must be isspace((unsigned char)....) Why and where can I find documentation about this? Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Sun Oct 7 10:51:58 2001 Delivered-To: freebsd-audit@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 4E23A37B407; Sun, 7 Oct 2001 10:51:52 -0700 (PDT) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id TAA01668; Sun, 7 Oct 2001 19:51:50 +0200 (CEST) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Mike Barcroft Cc: "Andrey A. Chernov" , Peter Pentchev , freebsd-net@FreeBSD.ORG, freebsd-audit@FreeBSD.ORG Subject: Re: [CFR] whois(1) out-of-bound access patch References: <20011004121640.C1959@ringworld.oblivion.bg> <20011004132801.A64960@nagual.pp.ru> <20011007133716.C37270@coffee.q9media.com> From: Dag-Erling Smorgrav Date: 07 Oct 2001 19:51:48 +0200 In-Reply-To: <20011007133716.C37270@coffee.q9media.com> Message-ID: Lines: 16 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike Barcroft writes: > Andrey A. Chernov writes: > > On Thu, Oct 04, 2001 at 12:16:40 +0300, Peter Pentchev wrote: > > > + if ((len == 0) || !isspace(buf[len - 1])) { > > Must be isspace((unsigned char)....) > Why and where can I find documentation about this? If buf[len - 1] is a char (which is signed), non-ASCII characters will be sign-extended unless you cast to unsigned char. It so happens that it doesn't make any difference for isspace() because in the character sets we use, no space characters have the high bit set, but strictly speaking you still need the cast. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Sun Oct 7 11:48:37 2001 Delivered-To: freebsd-audit@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id AFC6237B407; Sun, 7 Oct 2001 11:48:32 -0700 (PDT) Received: (from ache@localhost) by nagual.pp.ru (8.11.6/8.11.6) id f97ImT232303; Sun, 7 Oct 2001 22:48:29 +0400 (MSD) (envelope-from ache) Date: Sun, 7 Oct 2001 22:48:29 +0400 From: "Andrey A. Chernov" To: Mike Barcroft Cc: Peter Pentchev , freebsd-net@FreeBSD.ORG, freebsd-audit@FreeBSD.ORG Subject: Re: [CFR] whois(1) out-of-bound access patch Message-ID: <20011007224829.A32240@nagual.pp.ru> References: <20011004121640.C1959@ringworld.oblivion.bg> <20011004132801.A64960@nagual.pp.ru> <20011007133716.C37270@coffee.q9media.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011007133716.C37270@coffee.q9media.com> User-Agent: Mutt/1.3.21i Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Oct 07, 2001 at 13:37:16 -0400, Mike Barcroft wrote: > > > > Must be isspace((unsigned char)....) > > Why and where can I find documentation about this? isspace(3) -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Sun Oct 7 17:38:27 2001 Delivered-To: freebsd-audit@freebsd.org Received: from coffee.q9media.com (coffee.q9media.com [216.94.229.19]) by hub.freebsd.org (Postfix) with ESMTP id E8A6437B409; Sun, 7 Oct 2001 17:38:14 -0700 (PDT) Received: (from mike@localhost) by coffee.q9media.com (8.11.6/8.11.6) id f980cqI44444; Sun, 7 Oct 2001 20:38:52 -0400 (EDT) (envelope-from mike) Date: Sun, 7 Oct 2001 20:38:52 -0400 From: Mike Barcroft To: "Todd C. Miller" Cc: Peter Pentchev , freebsd-net@FreeBSD.ORG, freebsd-audit@FreeBSD.ORG Subject: Final Patch for Review (was Re: [CFR] whois(1) out-of-bound access patch) Message-ID: <20011007203852.G37270@coffee.q9media.com> References: <20011004121640.C1959@ringworld.oblivion.bg> <20011004121933.B31795@coffee.q9media.com> <200110041650.f94GoL10010161@xerxes.courtesan.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200110041650.f94GoL10010161@xerxes.courtesan.com>; from Todd.Miller@courtesan.com on Thu, Oct 04, 2001 at 10:50:20AM -0600 Organization: The FreeBSD Project Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Todd C. Miller writes: > In message <20011004121933.B31795@coffee.q9media.com> > so spake Mike Barcroft (mike): > > > Would you please test the attached patch and confirm that it solves > > the problem? If it does, I'll commit it today. > > I doubt that is sufficient as "buf" is treated as a NUL terminated > string in the calls to strstr(). Also note that it is not necessary > to copy the buffer each time as in the original patch. You can > only get a line w/o a newline as the last line before EOF. After some discussion off the mailing list with Peter, I've come up with a total solution that is fairly elegant, but requires the new libc function strnstr(3) I posted earlier. Most of the patch is a cleanup of the current code. I'd appreciate reviews of this. I plan on committing it in a few days. The patch is at the end of this message and also at: http://people.FreeBSD.org/~mike/patches/whois.20011007.diff Best regards, Mike Barcroft ---------------------------------------------------------------------- whois.20011007.diff o Treat a buffer as a non-NUL terminated string, because the whois server may not return a new line character on the final line. o Remove the whois.networksolutions.com fallback code, which is no longer needed. o Instead of determining a hostname by terminating it when we see whitespace, only allow hostname characters and terminate the string when it's not such a character. o Add a small optimization in a for loop. PR: 30968 MFC after: 4 days Index: whois.c =================================================================== RCS file: /cvs/src/usr.bin/whois/whois.c,v retrieving revision 1.24 diff -u -r1.24 whois.c --- whois.c 5 Aug 2001 19:37:12 -0000 1.24 +++ whois.c 7 Oct 2001 21:38:04 -0000 @@ -71,11 +71,11 @@ #define SNICHOST "whois.6bone.net" #define DEFAULT_PORT "whois" #define WHOIS_SERVER_ID "Whois Server: " -#define NO_MATCH_ID "No match for \"" #define WHOIS_RECURSE 0x01 -#define WHOIS_INIC_FALLBACK 0x02 -#define WHOIS_QUICK 0x04 +#define WHOIS_QUICK 0x02 + +#define ishost(h) (isalnum((unsigned char)h) || h == '.' || h == '-') const char *ip_whois[] = { RNICHOST, PNICHOST, NULL }; const char *port = DEFAULT_PORT; @@ -164,7 +164,7 @@ use_qnichost = 1; host = NICHOST; if (!(flags & WHOIS_QUICK)) - flags |= WHOIS_INIC_FALLBACK | WHOIS_RECURSE; + flags |= WHOIS_RECURSE; } while (argc--) { if (country != NULL) { @@ -251,8 +251,8 @@ { FILE *sfi, *sfo; struct addrinfo *res2; - char *buf, *nhost, *p; - int i, nomatch, s; + char *buf, *host, *nhost, *p; + int i, s; size_t len; for (; res; res = res->ai_next) { @@ -273,45 +273,34 @@ fprintf(sfo, "%s\r\n", name); fflush(sfo); nhost = NULL; - nomatch = 0; while ((buf = fgetln(sfi, &len)) != NULL) { - while (len && isspace(buf[len - 1])) + while (len > 0 && isspace((unsigned char)buf[len - 1])) buf[--len] = '\0'; + printf("%.*s\n", (int)len, buf); if ((flags & WHOIS_RECURSE) && nhost == NULL) { - p = strstr(buf, WHOIS_SERVER_ID); - if (p != NULL) { - p += sizeof(WHOIS_SERVER_ID) - 1; - if ((len = strcspn(p, " \t\n\r")) != 0) { - s_asprintf(&nhost, "%s", p); + host = strnstr(buf, WHOIS_SERVER_ID, len); + if (host != NULL) { + host += sizeof(WHOIS_SERVER_ID) - 1; + for (p = host; p < buf + len; p++) { + if (!ishost(*p)) { + *p = '\0'; + break; + } } + s_asprintf(&nhost, "%.*s", + (int)(buf + len - host), host); } else { for (i = 0; ip_whois[i] != NULL; i++) { - if (strstr(buf, ip_whois[i]) == NULL) + if (strnstr(buf, ip_whois[i], len) == + NULL) continue; s_asprintf(&nhost, "%s", ip_whois[i]); + break; } } } - - if ((flags & WHOIS_INIC_FALLBACK) && nhost == NULL && - !nomatch && (p = strstr(buf, NO_MATCH_ID)) != NULL) { - p += sizeof(NO_MATCH_ID) - 1; - if ((len = strcspn(p, "\"")) && - strncasecmp(name, p, len) == 0 && - name[len] == '\0' && - strchr(name, '.') == NULL) - nomatch = 1; - } - printf("%s\n", buf); } - - /* Do second lookup as needed. */ - if (nomatch && nhost == NULL) { - printf("Looking up %s at %s.\n\n", name, INICHOST); - s_asprintf(&nhost, "%s", INICHOST); - } - if (nhost != NULL) { if ((res2 = gethostinfo(nhost, 0)) == NULL) { free(nhost); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Mon Oct 8 17:46:28 2001 Delivered-To: freebsd-audit@freebsd.org Received: from holly.dyndns.org (adsl-208-191-149-224.dsl.hstntx.swbell.net [208.191.149.224]) by hub.freebsd.org (Postfix) with ESMTP id 38B1837B406; Mon, 8 Oct 2001 17:46:23 -0700 (PDT) Received: (from chris@localhost) by holly.dyndns.org (8.11.6/8.9.3) id f990krF06222; Mon, 8 Oct 2001 19:46:54 -0500 (CDT) (envelope-from chris) Date: Mon, 8 Oct 2001 19:46:43 -0500 From: Chris Costello To: Mike Barcroft Cc: "Todd C. Miller" , Peter Pentchev , freebsd-net@FreeBSD.ORG, freebsd-audit@FreeBSD.ORG Subject: Re: Final Patch for Review (was Re: [CFR] whois(1) out-of-bound access patch) Message-ID: <20011008194642.A696@holly.calldei.com> Reply-To: chris@FreeBSD.ORG References: <20011004121640.C1959@ringworld.oblivion.bg> <20011004121933.B31795@coffee.q9media.com> <200110041650.f94GoL10010161@xerxes.courtesan.com> <20011007203852.G37270@coffee.q9media.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011007203852.G37270@coffee.q9media.com>; from mike@FreeBSD.ORG on Sun, Oct 07, 2001 at 08:38:52PM -0400 Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sunday, October 07, 2001, Mike Barcroft wrote: > for (i = 0; ip_whois[i] != NULL; i++) { > - if (strstr(buf, ip_whois[i]) == NULL) > + if (strnstr(buf, ip_whois[i], len) == > + NULL) > continue; > s_asprintf(&nhost, "%s", ip_whois[i]); > + break; Should be for (i = 0; ip_whois[i] != NULL; i++) { if (strnstr(buf, ip_whois[i]) != NULL) { s_asprintf(&nhost, "%s", ip_whois[i]); break; } } for simplicity's sake. -- +-------------------+------------------------------------------+ | Chris Costello | To iterate is human; to recurse, divine. | | chris@FreeBSD.org | | +-------------------+------------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Tue Oct 9 18:27:46 2001 Delivered-To: freebsd-audit@freebsd.org Received: from rodney.cnchost.com (rodney.concentric.net [207.155.252.4]) by hub.freebsd.org (Postfix) with ESMTP id 69D7637B406; Tue, 9 Oct 2001 18:27:39 -0700 (PDT) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by rodney.cnchost.com id VAA22073; Tue, 9 Oct 2001 21:27:38 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <200110100127.VAA22073@rodney.cnchost.com> To: Mike Barcroft Cc: freebsd-hackers@FreeBSD.org, audit@freebsd.org Subject: Re: strnstr(3) - New libc function for review In-reply-to: Your message of "Thu, 04 Oct 2001 21:57:06 EDT." <20011004215706.B34530@coffee.q9media.com> Date: Tue, 09 Oct 2001 18:27:38 -0700 From: Bakul Shah Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I would appreciate comments/reviews of the following new addition to > libc. It is largely based off the current strstr(3) implementation. Sorry for not getting to this sooner. > /* > * Find the first occurrence of find in s, where the search is limited to the > * first slen characters of s. > */ > char * > strnstr(s, find, slen) > const char *s; > const char *find; > size_t slen; > { > char c, sc; > size_t len; > > if ((c = *find++) != '\0') { > len = strlen(find); > do { > do { > if ((sc = *s++) == '\0' || slen-- < 1) > return (NULL); > } while (sc != c); > if (len > slen) > return (NULL); > } while (strncmp(s, find, len) != 0); > s--; > } > return ((char *)s); > } Why not pass the length of the pattern as well? Regardless, why not use simpler code that is easier to prove right? char* strnstr(const char *s, size_t slen, const chat *p, size_t plen) { while (slen >= plen) { if (strncmp(s, p, plen) == 0) return (char*)s; s++, slen--; } return 0; } Another reason for passing in both string lengths is to allow switching to a more efficient algorithm. The above algorithm runs in slen*plen time. Other more efficient algorithms have a startup cost that can be hiddne for a fairly moderate value of slen*plen. So you'd insert something like if (worth_it_to_run_KMP_algo(splen, plen)) return kmp_strnstr(s, slen, p, plen); right above the while loop. This makes such functions useful for much larger strings (e.g. when you have mmapped in the whole file). -- bakul To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Tue Oct 9 18:34:15 2001 Delivered-To: freebsd-audit@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id A6E5737B403; Tue, 9 Oct 2001 18:34:10 -0700 (PDT) Received: (from ache@localhost) by nagual.pp.ru (8.11.6/8.11.6) id f9A1Y3L86219; Wed, 10 Oct 2001 05:34:04 +0400 (MSD) (envelope-from ache) Date: Wed, 10 Oct 2001 05:34:03 +0400 From: "Andrey A. Chernov" To: Bakul Shah Cc: Mike Barcroft , freebsd-hackers@FreeBSD.ORG, audit@FreeBSD.ORG Subject: Re: strnstr(3) - New libc function for review Message-ID: <20011010053402.A86108@nagual.pp.ru> References: <20011004215706.B34530@coffee.q9media.com> <200110100127.VAA22073@rodney.cnchost.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200110100127.VAA22073@rodney.cnchost.com> User-Agent: Mutt/1.3.21i Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Oct 09, 2001 at 18:27:38 -0700, Bakul Shah wrote: > > Why not pass the length of the pattern as well? Regardless, > why not use simpler code that is easier to prove right? > > char* > strnstr(const char *s, size_t slen, const chat *p, size_t plen) It clearly violates API, passing two lengths. Remember that FreeBSD is not unique with strnstr(), some others have it too. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Tue Oct 9 19:11:29 2001 Delivered-To: freebsd-audit@freebsd.org Received: from coffee.q9media.com (coffee.q9media.com [216.94.229.19]) by hub.freebsd.org (Postfix) with ESMTP id 020A537B406; Tue, 9 Oct 2001 19:11:21 -0700 (PDT) Received: (from mike@localhost) by coffee.q9media.com (8.11.6/8.11.6) id f9A2CLp50300; Tue, 9 Oct 2001 22:12:21 -0400 (EDT) (envelope-from mike) Date: Tue, 9 Oct 2001 22:12:20 -0400 From: Mike Barcroft To: Bakul Shah Cc: audit@FreeBSD.org Subject: Re: strnstr(3) - New libc function for review Message-ID: <20011009221220.C49828@coffee.q9media.com> References: <20011004215706.B34530@coffee.q9media.com> <200110100127.VAA22073@rodney.cnchost.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200110100127.VAA22073@rodney.cnchost.com>; from bakul@bitblocks.com on Tue, Oct 09, 2001 at 06:27:38PM -0700 Organization: The FreeBSD Project Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [-hackers moved back to BCC. I had intended follow-ups to go to -audit, but there might be some interested hackers reading now. Follow-ups to this message go to -audit, thanks! :) ] Bakul Shah writes: > > I would appreciate comments/reviews of the following new addition to > > libc. It is largely based off the current strstr(3) implementation. > > Sorry for not getting to this sooner. > > > /* > > * Find the first occurrence of find in s, where the search is limited to the > > * first slen characters of s. > > */ > > char * > > strnstr(s, find, slen) > > const char *s; > > const char *find; > > size_t slen; > > { > > char c, sc; > > size_t len; > > > > if ((c = *find++) != '\0') { > > len = strlen(find); > > do { > > do { > > if ((sc = *s++) == '\0' || slen-- < 1) > > return (NULL); > > } while (sc != c); > > if (len > slen) > > return (NULL); > > } while (strncmp(s, find, len) != 0); > > s--; > > } > > return ((char *)s); > > } > > Why not pass the length of the pattern as well? Regardless, This is probably not needed for most uses for this. It would be rare to have two non-NUL terminated strings. On the other hand, this could be implemented in the future, if it's seen as useful. strnstr(3) could easily be modified to call a strnstrn() and use strlen(3) to get the missing size field. > why not use simpler code that is easier to prove right? > > char* > strnstr(const char *s, size_t slen, const chat *p, size_t plen) This prototype is inconsistent with any strn...(3) functions that I'm aware of. > { > while (slen >= plen) { > if (strncmp(s, p, plen) == 0) > return (char*)s; > s++, slen--; > } It seems to me, it would be a pessimization to call strncmp(3) when you don't even have one character that matches. > return 0; > } Do you mean: return (NULL) ? > Another reason for passing in both string lengths is to allow > switching to a more efficient algorithm. The above algorithm > runs in slen*plen time. Other more efficient algorithms have > a startup cost that can be hiddne for a fairly moderate value > of slen*plen. So you'd insert something like > > if (worth_it_to_run_KMP_algo(splen, plen)) > return kmp_strnstr(s, slen, p, plen); > > right above the while loop. This makes such functions > useful for much larger strings (e.g. when you have > mmapped in the whole file). Yes, I recall seeing these algorithms discussed recently and I believe it was concluded that making strstr(3) use one of these more advanced algorithms would be a pessimization for most cases. That said, don't let me hold you back from proposing alternative or complimentary functions to strnstr(3). Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Wed Oct 10 4:29:22 2001 Delivered-To: freebsd-audit@freebsd.org Received: from nas.dgap.mipt.ru (nas.dgap.mipt.ru [194.85.81.203]) by hub.freebsd.org (Postfix) with ESMTP id 00D1C37B409; Wed, 10 Oct 2001 04:29:12 -0700 (PDT) Received: from localhost (andrew@localhost) by nas.dgap.mipt.ru (8.11.6/8.11.6) with ESMTP id f9ABT1m50064; Wed, 10 Oct 2001 15:29:01 +0400 (MSD) (envelope-from andrew@nas.dgap.mipt.ru) Date: Wed, 10 Oct 2001 15:29:00 +0400 (MSD) From: "Andrew L. Neporada" To: Mike Barcroft Cc: audit@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: strnstr(3) - New libc function for review In-Reply-To: <20011004215706.B34530@coffee.q9media.com> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1603302548-1002713340=:50053" Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1603302548-1002713340=:50053 Content-Type: TEXT/PLAIN; charset=US-ASCII I think you should write in ststr.3 that strnstr locates first occurrence of null-terminated string 'little' in ___null-terminated___ string 'big'. Andrew. P.S. Because str(n)str functions deal with null-terminated strings (i.e. we don't know sizes of strings), it is impossible to write algorithm, that will work faster (in average) than current implementation. P.P.S. In the case of binary strings it is possible to implement faster search -- see attachment. On Thu, 4 Oct 2001, Mike Barcroft wrote: > [BCC'd to -hackers for additional comments.] > > Hello, > I would appreciate comments/reviews of the following new addition to > libc. It is largely based off the current strstr(3) implementation. > > Patch attached and also available at: > http://people.FreeBSD.org/~mike/patches/strnstr.diff > > > Best regards, > Mike Barcroft > --0-1603302548-1002713340=:50053 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="strstr.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: bstrstr.c Content-Disposition: attachment; filename="strstr.c" I2luY2x1ZGUgPHN5cy90eXBlcy5oPg0KI2luY2x1ZGUgPHN5cy90aW1lLmg+ DQojaW5jbHVkZSA8bGltaXRzLmg+DQojaW5jbHVkZSA8c3RkaW8uaD4NCiNp bmNsdWRlIDxzdGRsaWIuaD4NCiNpbmNsdWRlIDxzdHJpbmcuaD4NCg0KI2Rl ZmluZQlTVFJTWgkoMTAwKjEwMjQpDQojZGVmaW5lCVBBVFNaCTUwMA0KI2Rl ZmluZQlUUllTCTEwMA0KDQp2b2lkICoNCmJzdHJzdHIocywgc2xlbiwgcCwg cGxlbikNCglyZWdpc3RlciBjb25zdCB2b2lkCSpzLCAqcDsNCglzaXplX3QJ CQlzbGVuLCBwbGVuOw0Kew0KCXJlZ2lzdGVyIGNvbnN0IHVfY2hhciAJKnN0 ciwgKnN1YnN0cjsNCglyZWdpc3RlciBzaXplX3QJCWksIG1heF9zaGlmdCwg Y3Vycl9zaGlmdDsNCg0KCXNpemVfdAkJCXNoaWZ0W1VDSEFSX01BWCArIDFd Ow0KDQoJaWYgKHMgPT0gTlVMTCB8fCBwID09IE5VTEwgfHwgcGxlbiA+IHNs ZW4gfHwgc2xlbiA9PSAwIHx8IHBsZW4gPT0gMCkNCgkJcmV0dXJuIChOVUxM KTsNCg0KCXN0ciA9IChjb25zdCB1X2NoYXIgKilzOw0KCXN1YnN0ciA9IChj b25zdCB1X2NoYXIgKilwOw0KDQoJZm9yIChpID0gMDsgaSA8PSBVQ0hBUl9N QVg7IGkrKykgc2hpZnRbaV0gPSBwbGVuICsgMTsNCglmb3IgKGkgPSAwOyBp IDwgcGxlbjsgaSsrKSBzaGlmdFtzdWJzdHJbaV1dID0gcGxlbiAtIGk7DQoN CglpID0gMDsNCgltYXhfc2hpZnQgPSBzbGVuIC0gcGxlbjsNCgl3aGlsZSAo aSA8PSBtYXhfc2hpZnQpIHsNCgkJaWYgKCpzdHIgPT0gKnN1YnN0ciAmJiAh bWVtY21wKHN0ciArIDEsIHN1YnN0ciArIDEsIHBsZW4gLTEpKQ0KCQkJcmV0 dXJuICgodm9pZCAqKXN0cik7DQoJCWN1cnJfc2hpZnQgPSBzaGlmdFtzdHJb cGxlbl1dOw0KCQlzdHIgKz0gY3Vycl9zaGlmdDsNCgkJaSArPSBjdXJyX3No aWZ0Ow0KCX0NCglyZXR1cm4gKE5VTEwpOw0KfQ0KDQppbnQNCm1haW4odm9p ZCkNCnsNCgljaGFyCQkqc3RyOw0KCXN0cnVjdCB0aW1ldmFsCWJlZm9yZSwg YWZ0ZXI7DQoJc2l6ZV90CQlpOw0KDQoNCglzcmFuZG9tZGV2KCk7DQoJc3Ry ID0gKGNoYXIgKiltYWxsb2MoU1RSU1ogKyBQQVRTWiArIDEpOw0KCWlmICgh c3RyKSB7DQoJCXByaW50Zigibm8gbWVtXG4iKTsNCgkJZXhpdCgxKTsNCgl9 DQoJZm9yIChpID0gMDsgaSA8IFNUUlNaICsgUEFUU1o7IGkrKykgew0KCQlz dHJbaV0gPSByYW5kb20oKSAmIDB4ZmY7DQoJCWlmICghc3RyW2ldKSBzdHJb aV0gPSAxOw0KCX0NCglzdHJbU1RSU1ogKyBQQVRTWl0gPSAwOw0KDQoJcHJp bnRmKCJzbGVuID0gJWQsIHBsZW4gPSAlZFxuIiwgU1RSU1ogKyBQQVRTWiwg UEFUU1opOw0KCWdldHRpbWVvZmRheSgmYmVmb3JlLCBOVUxMKTsNCglmb3Ig KGkgPSAwOyBpIDwgVFJZUzsgaSsrKQ0KCQlzdHJzdHIoc3RyLCBzdHIgKyBT VFJTWik7DQoJZ2V0dGltZW9mZGF5KCZhZnRlciwgTlVMTCk7DQoJYWZ0ZXIu dHZfc2VjIC09IGJlZm9yZS50dl9zZWM7DQoJYWZ0ZXIudHZfdXNlYyAtPSBi ZWZvcmUudHZfdXNlYzsNCglwcmludGYoIk9sZDogJWYgc2VjXG4iLCAoYWZ0 ZXIudHZfc2VjICsgYWZ0ZXIudHZfdXNlYy8xMDAwMDAwLjApL1RSWVMpOw0K DQoJZ2V0dGltZW9mZGF5KCZiZWZvcmUsIE5VTEwpOw0KCWZvciAoaSA9IDA7 IGkgPCBUUllTOyBpKyspDQoJCWJzdHJzdHIoc3RyLCBTVFJTWiArIFBBVFNa LCBzdHIgKyBTVFJTWiwgUEFUU1opOw0KCWdldHRpbWVvZmRheSgmYWZ0ZXIs IE5VTEwpOw0KCWFmdGVyLnR2X3NlYyAtPSBiZWZvcmUudHZfc2VjOw0KCWFm dGVyLnR2X3VzZWMgLT0gYmVmb3JlLnR2X3VzZWM7DQoJcHJpbnRmKCJOZXc6 ICVmIHNlY1xuIiwgKGFmdGVyLnR2X3NlYyArIGFmdGVyLnR2X3VzZWMvMTAw MDAwMC4wKS9UUllTKTsNCglmcmVlKHN0cik7DQoJcmV0dXJuICgwKTsNCn0N Cg== --0-1603302548-1002713340=:50053-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Wed Oct 10 8:51:10 2001 Delivered-To: freebsd-audit@freebsd.org Received: from coffee.q9media.com (coffee.q9media.com [216.94.229.19]) by hub.freebsd.org (Postfix) with ESMTP id B1E3737B40B for ; Wed, 10 Oct 2001 08:51:07 -0700 (PDT) Received: (from mike@localhost) by coffee.q9media.com (8.11.6/8.11.6) id f9AFqBG51796; Wed, 10 Oct 2001 11:52:11 -0400 (EDT) (envelope-from mike) Date: Wed, 10 Oct 2001 11:52:10 -0400 From: Mike Barcroft To: "Andrew L. Neporada" Cc: audit@FreeBSD.ORG Subject: Re: strnstr(3) - New libc function for review Message-ID: <20011010115210.E49828@coffee.q9media.com> References: <20011004215706.B34530@coffee.q9media.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from andrew@nas.dgap.mipt.ru on Wed, Oct 10, 2001 at 03:29:00PM +0400 Organization: The FreeBSD Project Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [-hackers removed from CC] Andrew L. Neporada writes: > I think you should write in ststr.3 that strnstr locates first occurrence > of null-terminated string 'little' in ___null-terminated___ string 'big'. No, that's inconsistent with existing strn...() functions and totally defeats the purpose of my addition. To quote from my patch: : Add a new libc function, strnstr(3), which allows one to limit the : number of characters that are searched. This is especially useful : with file operations and non-NUL terminated strings. > P.S. Because str(n)str functions deal with null-terminated strings > (i.e. we don't know sizes of strings), it is impossible to write > algorithm, that will work faster (in average) than current implementation. See above. > P.P.S. In the case of binary strings it is possible to implement faster > search -- see attachment. Yes. Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Wed Oct 10 9:16:36 2001 Delivered-To: freebsd-audit@freebsd.org Received: from nas.dgap.mipt.ru (nas.dgap.mipt.ru [194.85.81.203]) by hub.freebsd.org (Postfix) with ESMTP id 5595337B40E; Wed, 10 Oct 2001 09:16:31 -0700 (PDT) Received: from localhost (andrew@localhost) by nas.dgap.mipt.ru (8.11.6/8.11.6) with ESMTP id f9AGGTA51578; Wed, 10 Oct 2001 20:16:29 +0400 (MSD) (envelope-from andrew@nas.dgap.mipt.ru) Date: Wed, 10 Oct 2001 20:16:27 +0400 (MSD) From: "Andrew L. Neporada" To: Mike Barcroft Cc: audit@FreeBSD.ORG Subject: Re: strnstr(3) - New libc function for review In-Reply-To: <20011010115210.E49828@coffee.q9media.com> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-2138966051-1002730587=:51458" Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-2138966051-1002730587=:51458 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 10 Oct 2001, Mike Barcroft wrote: > [-hackers removed from CC] > > Andrew L. Neporada writes: > > I think you should write in ststr.3 that strnstr locates first occurrence > > of null-terminated string 'little' in ___null-terminated___ string 'big'. > > No, that's inconsistent with existing strn...() functions and totally > defeats the purpose of my addition. > Check attached test program. It prints "NULL". So either implementation or man page is wrong. > To quote from my patch: > : Add a new libc function, strnstr(3), which allows one to limit the > : number of characters that are searched. This is especially useful > : with file operations and non-NUL terminated strings. > > > P.S. Because str(n)str functions deal with null-terminated strings > > (i.e. we don't know sizes of strings), it is impossible to write > > algorithm, that will work faster (in average) than current implementation. > > See above. > > > P.P.S. In the case of binary strings it is possible to implement faster > > search -- see attachment. > > Yes. Could you please comment my bstrstr implementation? > > > Best regards, > Mike Barcroft > Andrew. --0-2138966051-1002730587=:51458 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="strnstr_test.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: strnstr_test.c Content-Disposition: attachment; filename="strnstr_test.c" I2luY2x1ZGUgPHN0cmluZy5oPg0KI2luY2x1ZGUgPHN0ZGlvLmg+DQoNCi8q DQogKiBGaW5kIHRoZSBmaXJzdCBvY2N1cnJlbmNlIG9mIGZpbmQgaW4gcywg d2hlcmUgdGhlIHNlYXJjaCBpcyBsaW1pdGVkIHRvIHRoZQ0KICogZmlyc3Qg c2xlbiBjaGFyYWN0ZXJzIG9mIHMuDQogKi8NCmNoYXIgKg0Kc3RybnN0cihz LCBmaW5kLCBzbGVuKQ0KCWNvbnN0IGNoYXIgKnM7DQoJY29uc3QgY2hhciAq ZmluZDsNCglzaXplX3Qgc2xlbjsNCnsNCgljaGFyIGMsIHNjOw0KCXNpemVf dCBsZW47DQoNCglpZiAoKGMgPSAqZmluZCsrKSAhPSAnXDAnKSB7DQoJCWxl biA9IHN0cmxlbihmaW5kKTsNCgkJZG8gew0KCQkJZG8gew0KCQkJCWlmICgo c2MgPSAqcysrKSA9PSAnXDAnIHx8IHNsZW4tLSA8IDEpDQoJCQkJCXJldHVy biAoTlVMTCk7DQoJCQl9IHdoaWxlIChzYyAhPSBjKTsNCgkJCWlmIChsZW4g PiBzbGVuKQ0KCQkJCXJldHVybiAoTlVMTCk7DQoJCX0gd2hpbGUgKHN0cm5j bXAocywgZmluZCwgbGVuKSAhPSAwKTsNCgkJcy0tOw0KCX0NCglyZXR1cm4g KChjaGFyICopcyk7DQp9DQoNCmludA0KbWFpbih2b2lkKQ0Kew0KCWNoYXIJ c3RyWzEwXSA9IHsnYScsICdiJywgJ2MnLCAnXDAnLCAnYScsICdiJywgJ2Mn LCAnZCcsICdlJywgJ2YnfTsNCgljaGFyCSpwYXQgPSAiYWJjZCI7DQoJY2hh cgkqcHRyOw0KDQoJcHRyID0gc3RybnN0cihzdHIsIHBhdCwgMTApOw0KCQ0K CWlmIChwdHIgPT0gTlVMTCkNCgkJcHJpbnRmKCJOVUxMXG4iKTsNCgllbHNl DQoJCXByaW50ZigiJXNcbiIpOw0KCWV4aXQoMCk7DQp9DQo= --0-2138966051-1002730587=:51458-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Wed Oct 10 10:25:54 2001 Delivered-To: freebsd-audit@freebsd.org Received: from valiant.cnchost.com (valiant.concentric.net [207.155.252.9]) by hub.freebsd.org (Postfix) with ESMTP id 4707237B408; Wed, 10 Oct 2001 10:25:42 -0700 (PDT) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by valiant.cnchost.com id NAA06941; Wed, 10 Oct 2001 13:25:37 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <200110101725.NAA06941@valiant.cnchost.com> To: Mike Barcroft Cc: audit@FreeBSD.org Subject: Re: strnstr(3) - New libc function for review In-reply-to: Your message of "Tue, 09 Oct 2001 22:12:20 EDT." <20011009221220.C49828@coffee.q9media.com> Date: Wed, 10 Oct 2001 10:25:25 -0700 From: Bakul Shah Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [synposis: I am arguing to make strnstrn a part of libc. strnstrn instead of, or in addition to, strnstr. strnstrn is defined as char * strnstrn(const char* s, size_t slen, const char* p, size_t plen) ] > This is probably not needed for most uses for this. It would be rare > to have two non-NUL terminated strings. On the other hand, this could > be implemented in the future, if it's seen as useful. strnstr(3) > could easily be modified to call a strnstrn() and use strlen(3) to get > the missing size field. Well, as you point out strnstr (as per your definition) is not general enough but strnstrn is. The latter will accept non nul terminated strings and can be used to build strnstr: strnstr(a,b,l) == strnstrn(a,l, b, strlen(b)) Actually it is not so rare to have two non nul terminated strings, for example when you are comparing a substring (part of a bigger string) against another string. strnstr will force nul-termination and you either have to allocate a new string or, worse (and the more frequent case), write a \nul into a string, while remembering to save and restore the overwritten char. This latter horrible habit is even enshrined in strtok, strsep and friends. I don't care much about the name but do care about generality (IMHO the names str{,n}chr and str{,n}str stink -- naming a function after its argument types is pretty strange! But that is a separate discussion:). > > { > > while (slen >= plen) { > > if (strncmp(s, p, plen) == 0) > > return (char*)s; > > s++, slen--; > > } > > It seems to me, it would be a pessimization to call strncmp(3) when > you don't even have one character that matches. Good point! Okay, how about the following? It should be as efficient as your version. while (slen >= plen) { if (*s == *p && strncmp(s+1, p+1, plen-1) == 0) return (char*)s; s++; slen--; } > > return 0; > > Do you mean: return (NULL) ? I mildly prefer 0 and removal of unnecessary parens but that is just a style issue. Not important. > Yes, I recall seeing these algorithms discussed recently and I believe > it was concluded that making strstr(3) use one of these more advanced > algorithms would be a pessimization for most cases. That said, don't > let me hold you back from proposing alternative or complimentary > functions to strnstr(3). No proof was proffered either way. I happen to believe it is a win even when you are searching sub 100 byte strings but I'll shut up until I can show that (or Andrew L. Neporada does that!). *If* it is a win, IMHO it is better to have one interface (strnstrn or whatever) that selects the appropriate algorithm for a number of reasons: a) most people simply want to use a function that meets their needs without doing any algorithmic analysis. They benefit automatically. b) if tomorrow you come up with a faster algorithm, a new strnstrn implementation that can take advantage of that will benefit existing programs as well (if they use shared libs). This is a philosophical argument about library design (not just strnstrn) which is why I put freebsd-hackers back in bcc:. To me it makes sense to provide algorithm specific functions *and* a generic function that selects the best one based on inputs. Use the specific version when you know exatcly what you are doing and want a better control over the behavior of your program; use the generic version when you something `fast' but don't care beyond that. Sort of like providing VM for the masses -- not everyone needs or wants to do their own memory management! -- bakul To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Wed Oct 10 17: 8:54 2001 Delivered-To: freebsd-audit@freebsd.org Received: from coffee.q9media.com (coffee.q9media.com [216.94.229.19]) by hub.freebsd.org (Postfix) with ESMTP id 8325037B401 for ; Wed, 10 Oct 2001 17:08:48 -0700 (PDT) Received: (from mike@localhost) by coffee.q9media.com (8.11.6/8.11.6) id f9B09lm52704; Wed, 10 Oct 2001 20:09:47 -0400 (EDT) (envelope-from mike) Date: Wed, 10 Oct 2001 20:09:47 -0400 From: Mike Barcroft To: Bakul Shah Cc: audit@FreeBSD.org Subject: Re: strnstr(3) - New libc function for review Message-ID: <20011010200947.F49828@coffee.q9media.com> References: <20011009221220.C49828@coffee.q9media.com> <200110101725.NAA06941@valiant.cnchost.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200110101725.NAA06941@valiant.cnchost.com>; from bakul@bitblocks.com on Wed, Oct 10, 2001 at 10:25:25AM -0700 Organization: The FreeBSD Project Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bakul Shah writes: > [synposis: > I am arguing to make strnstrn a part of libc. strnstrn instead > of, or in addition to, strnstr. strnstrn is defined as > char * strnstrn(const char* s, size_t slen, const char* p, size_t plen) > ] > > > This is probably not needed for most uses for this. It would be rare > > to have two non-NUL terminated strings. On the other hand, this could > > be implemented in the future, if it's seen as useful. strnstr(3) > > could easily be modified to call a strnstrn() and use strlen(3) to get > > the missing size field. > > Well, as you point out strnstr (as per your definition) is > not general enough but strnstrn is. The latter will accept > non nul terminated strings and can be used to build strnstr: > > strnstr(a,b,l) == strnstrn(a,l, b, strlen(b)) > > Actually it is not so rare to have two non nul terminated > strings, for example when you are comparing a substring (part > of a bigger string) against another string. strnstr will > force nul-termination and you either have to allocate a new > string or, worse (and the more frequent case), write a \nul > into a string, while remembering to save and restore the > overwritten char. This latter horrible habit is even > enshrined in strtok, strsep and friends. I did do some research into current uses of strnstr() and strnstrn(). strnstr() seemed to be the more popular of the two. Yes, strnstrn() would be more general, but I really can't see a lot of uses for it. > I don't care much about the name but do care about generality > (IMHO the names str{,n}chr and str{,n}str stink -- naming a > function after its argument types is pretty strange! But > that is a separate discussion:). > > > > { > > > while (slen >= plen) { > > > if (strncmp(s, p, plen) == 0) > > > return (char*)s; > > > s++, slen--; > > > } > > > > It seems to me, it would be a pessimization to call strncmp(3) when > > you don't even have one character that matches. > > Good point! Okay, how about the following? It should be as > efficient as your version. > > while (slen >= plen) { > if (*s == *p && strncmp(s+1, p+1, plen-1) == 0) > return (char*)s; > s++; slen--; > } You missed the case where "If little is an empty string, big is returned". > > > return 0; > > > > Do you mean: return (NULL) ? > > I mildly prefer 0 and removal of unnecessary parens but that > is just a style issue. Not important. Actually style is quite important, see style(9). > > Yes, I recall seeing these algorithms discussed recently and I believe > > it was concluded that making strstr(3) use one of these more advanced > > algorithms would be a pessimization for most cases. That said, don't > > let me hold you back from proposing alternative or complimentary > > functions to strnstr(3). > > No proof was proffered either way. I happen to believe it is > a win even when you are searching sub 100 byte strings but > I'll shut up until I can show that (or Andrew L. Neporada > does that!). *If* it is a win, IMHO it is better to have one > interface (strnstrn or whatever) that selects the appropriate > algorithm for a number of reasons: > > a) most people simply want to use a function that meets their > needs without doing any algorithmic analysis. They benefit > automatically. > > b) if tomorrow you come up with a faster algorithm, a new > strnstrn implementation that can take advantage of that > will benefit existing programs as well (if they use shared > libs). > > This is a philosophical argument about library design (not > just strnstrn) which is why I put freebsd-hackers back in > bcc:. To me it makes sense to provide algorithm specific > functions *and* a generic function that selects the best one > based on inputs. Use the specific version when you know > exatcly what you are doing and want a better control over the > behavior of your program; use the generic version when you > something `fast' but don't care beyond that. Sort of like > providing VM for the masses -- not everyone needs or wants to > do their own memory management! I don't see how strnstr(3) would impede future optimizations, you can just get the length by using strlen(3). Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Wed Oct 10 18: 2: 6 2001 Delivered-To: freebsd-audit@freebsd.org Received: from coffee.q9media.com (coffee.q9media.com [216.94.229.19]) by hub.freebsd.org (Postfix) with ESMTP id EF1D937B406 for ; Wed, 10 Oct 2001 18:02:03 -0700 (PDT) Received: (from mike@localhost) by coffee.q9media.com (8.11.6/8.11.6) id f9B126T52790; Wed, 10 Oct 2001 21:02:06 -0400 (EDT) (envelope-from mike) Date: Wed, 10 Oct 2001 21:02:06 -0400 From: Mike Barcroft To: "Andrew L. Neporada" Cc: audit@FreeBSD.ORG Subject: Re: strnstr(3) - New libc function for review Message-ID: <20011010210206.G49828@coffee.q9media.com> References: <20011010115210.E49828@coffee.q9media.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from andrew@nas.dgap.mipt.ru on Wed, Oct 10, 2001 at 08:16:27PM +0400 Organization: The FreeBSD Project Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Andrew L. Neporada writes: > On Wed, 10 Oct 2001, Mike Barcroft wrote: > > No, that's inconsistent with existing strn...() functions and totally > > defeats the purpose of my addition. > > Check attached test program. It prints "NULL". So either implementation or > man page is wrong. Yes, that's a documentation problem. I'll correct it today. strncmp(3) has a similar problem; I'll correct that as well. > > > P.P.S. In the case of binary strings it is possible to implement faster > > > search -- see attachment. > > > > Yes. > > Could you please comment my bstrstr implementation? I don't really understand the context. Are you proposing I use it instead of strnstr(3)? If so, that's not what strnstr(3) is intended to do; it's designed for strings only. Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message From owner-freebsd-audit Thu Oct 11 9: 3:11 2001 Delivered-To: freebsd-audit@freebsd.org Received: from nas.dgap.mipt.ru (nas.dgap.mipt.ru [194.85.81.203]) by hub.freebsd.org (Postfix) with ESMTP id 844DB37B401; Thu, 11 Oct 2001 09:02:59 -0700 (PDT) Received: from localhost (andrew@localhost) by nas.dgap.mipt.ru (8.11.6/8.11.6) with ESMTP id f9BG2uo56271; Thu, 11 Oct 2001 20:02:56 +0400 (MSD) (envelope-from andrew@nas.dgap.mipt.ru) Date: Thu, 11 Oct 2001 20:02:54 +0400 (MSD) From: "Andrew L. Neporada" To: Mike Barcroft Cc: audit@FreeBSD.org Subject: Re: strnstr(3) - New libc function for review In-Reply-To: <20011010210206.G49828@coffee.q9media.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 10 Oct 2001, Mike Barcroft wrote: > > I don't really understand the context. Are you proposing I use it > instead of strnstr(3)? If so, that's not what strnstr(3) is intended > to do; it's designed for strings only. No I propose it for searching binary substring in binary string. strnstr is now ok. > > Best regards, > Mike Barcroft > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message