Date: Thu, 15 Jul 1999 19:48:31 -0600 From: Brett Glass <brett@lariat.org> To: Sheldon Hearn <sheldonh@uunet.co.za> Cc: Warner Losh <imp@village.org>, Paul Hart <hart@iserver.com>, freebsd-security@FreeBSD.ORG Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Message-ID: <4.2.0.58.19990715194032.045ee340@localhost> In-Reply-To: <81297.932083955@axl.noc.iafrica.com> References: <Your message of "Thu, 15 Jul 1999 18:05:06 CST." <4.2.0.58.19990715180119.04723d20@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
At 02:12 AM 7/16/99 +0200, Sheldon Hearn wrote: >That'd break code that doesn't expect to have to pass the additional >argument that we've opted to allow for. Well, at this point, it's early enough to specify the function so that no such code is written. > > Or, even better, ALWAYS return the shortfall. The programmer can then > > discard the return value if he's really willing to ignore it (perhaps > > at his peril). > >Reality check: we're talking about portability here. That's why this is the time to set the standard sensibly -- before Solaris and other standard bearers have decided one way or the other. >If we take these >functions into our own libc, we really should make them work as expected >on other platforms. Right now, there's only one other platform doing it: OpenBSD. And it's still early enough to make OpenBSD consistent if there are strong arguments for the approach that is taken. >What I'm getting at here is that, while the strl* functions may be nice >(and Mike Smith's arguments are casting some serious doubt over that >idea) What arguments? (They must be on some list to which I'm not subscribed.) However, based on what Mike said to be at Def Con, I'm concerned that Mike's arguments might arise from a personality conflict with Theo. >they could certainly be nicer. At least two other vendors already >have a defined API for the functions. If we use them, we shouldn't break >that API. What I propose doesn't, put it does allow for more convenient >use of the functions. Alas, the approach you've taken makes the functions slower (You have to check an argument that's going to be a constant in all cases -- why not just provide two separate functions?), bigger (you have to check the number of arguments AND the value of the extra one), and semantically confusing (the meaning of the return value is influenced both by the presence and the value of an argument). I would not take the approach you've mentioned for this reason. --Brett 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.19990715194032.045ee340>