>
> > 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. \\ [EMAIL PROTECTED]
\\ -- Joseph Merrick \\ [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
