Date: Thu, 15 Jul 1999 17:47:03 -0600 From: Brett Glass <brett@lariat.org> To: Sheldon Hearn <sheldonh@uunet.co.za>, Warner Losh <imp@village.org> Cc: Paul Hart <hart@iserver.com>, freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Message-ID: <4.2.0.58.19990715174241.045f0550@localhost> In-Reply-To: <80530.932081904@axl.noc.iafrica.com> References: <Your message of "Thu, 15 Jul 1999 17:19:05 CST." <199907152319.RAA73667@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
How about returning the shortfall as the return value of the function? This would allow the programmer to wrap an "if" right around the function call and handle the error easily if the string was truncated. Making a check convenient would encourage programmers to insert it into their code. Having to write a separate test would actually discourage this practice and could lead to malfunctioning code. --Brett At 01:38 AM 7/16/99 +0200, Sheldon Hearn wrote: >On Thu, 15 Jul 1999 17:19:05 CST, Warner Losh wrote: > > > I *STRONGLY* support adding strl routines to FreeBSD's libc. I've had > > them in my local library for a long time, but haven't had the time to > > commit them. > >What do you think of this? > >" >size_t >strlcpy(char *dst, char *src, size_t len [, shortfall]); > >size_t >strlcat(char *dst, char *src, size_t len [, shortfall]); > >[...] > >RETURN VALUES > >If the optional shortfall argument is passed non-zero, the functions >return the number of characters from src that are missing in dst after >the operation. Otherwise, they return the length of dst. In either case, >the return value does not include the NUL terminator. >" > >This way, we get compatibility with the other vendors who've chosen to >implement the functions, but we also get the cheaper option Tim wants. >It'd be up to the other vendors to choose to implement the extension. > >I'll come up with a commit candidate in the next 48 hours and post a >URL, including a manpage replacement. The OpenBSD manpage for these >functions includes in DESCRIPTION too much that should be in HISTORY >(and perhaps IMPLEMENTATION NOTES). > >The only thing I can think of that would make this extension a bad idea >is va_alist processing cost. Is it significant? > >Ciao, >Sheldon. > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.2.0.58.19990715174241.045f0550>