From owner-freebsd-hackers Sat May 12 12: 8: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from tonnant.cnchost.com (tonnant.concentric.net [207.155.248.72]) by hub.freebsd.org (Postfix) with ESMTP id 82EEF37B423 for ; Sat, 12 May 2001 12:08:01 -0700 (PDT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by tonnant.cnchost.com id PAA13219; Sat, 12 May 2001 15:07:56 -0400 (EDT) [ConcentricHost SMTP Relay 1.11] Message-ID: <200105121907.PAA13219@tonnant.cnchost.com> To: dan@BSDpro.com Cc: freebsd-hackers@freebsd.org Subject: Re: adding a new function to libc In-reply-to: Your message of "Sat, 12 May 2001 02:10:45 EDT." <01051202104500.95296@blackhole.BSDpro.com> Date: Sat, 12 May 2001 12:07:56 -0700 From: Bakul Shah Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Any comments, suggestions, swears concerning adding a new function, > strndup(), to libc? Many very good programmers I know carry around a library of useful functions (and usually don't bother about inclusion in libc). So I would suggest first you should keep this function in your own library for a few years and *only* then, and only if from experience you truly think it to be generally useful should you propose it for inclusion in a standard library. And *when* you do that you should a) present a correct version of the function (not a buggy one as you did here) and, more importantly b) a clear explanation of its function including how boundary conditions are handled. For your own library you don't have to jump through these hoops; this is necessary only when you want to let loose one of your favorite functions on unsuspecting libc users! Then the function behavior must be fully and carefully specified. Even for your own use, as was suggested by Valentin Nechayev, the strangely named function "strnlen(str, max)" is a better lower level function since it guarantees "str" won't be traversed beyond "max" chars and it is likely to be useful in more situations. As suggested by Terry Lambert, `asnprintf' would be another alternative. Though IMHO these string functions have sprouted like weeds, for very little added functionality. The fact str[a-z]* is reserved namespace should tell you how bad the situation is. What is needed is a decent unicode string library, derived from the collective experience with perl scripts. Unicode strings should be counted instead of null terminated so we are talking about a brand new set of functions. May be such a library can be standardized in a future standards effort after some experience with it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message