From owner-freebsd-hackers Thu Jul 15 16:27:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id 454341562D for ; Thu, 15 Jul 1999 16:27:18 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id QAA01649; Thu, 15 Jul 1999 16:18:08 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907152318.QAA01649@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Julian Elischer Cc: Mike Smith , Tim Vanderhoek , Sheldon Hearn , Garance A Drosihn , Paul Hart , freebsd-hackers@FreeBSD.ORG Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) In-reply-to: Your message of "Thu, 15 Jul 1999 16:04:12 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Jul 1999 16:18:08 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > What's really stupid is that most of the time you're trying to use > > these functions to fix code that looks like: > > > > strcpy(buf, str1); > > strcat(buf, str2); > > strcat(buf, str3); > > without overflowing buf. This is dumb! Use asprintf instead: > > There was a talk on these (strlcpy(3) and strlcat(3)) at USENIX. > The logic as to their design was presented and I agree totally with > the way that the logic was played out into the functions. I'm inclined to disagree, simply because they take too fine-grained an approach to the problem. > > asprinf(&buf, "%s%s%s", str1, str2, str3); > > > > Very nice but not always applicable. Particularly when compiling > strings under algorythmic control. I'm not sure what "compiling strings under algorithmic control" is actually meant to mean. The only addition I'd want to make to asprintf() is reasprintf() which reallocs and appends to the end of an already existing string. > > No, it's not fast, but it _is_ robust. > > Why not be fast AND robust? > :-) The two are generally not compatible. > I like the new functions and would like to see them supported. Obviously, I'm not in agreement here. The original trend (assembling strings piecemeal) was expedient but not really a great idea in the long term. Likewise there are a plethora of hand-rolled string parsers that could be replaced with sscanf() these days. Adding fancier piecemeal operators just continues to encourage the old, unsafe style. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message