The information in the strncpy() / strncat() section is incorrect.<p>Firstly, strncpy() was <i>not</i> designed to be a "safer strcpy()" at all. It was designed for storing strings in the manner of original UNIX directory entries: in a fixed size buffer, null-padded only if the stored string is shorter than the buffer. This is why it fills the buffer with nulls, and why it doesn't necessarily null-terminate the destination.<p>Secondly, contrary to what the article implies, strncat() does <i>not</i> work this way: strncat() <i>always</i> null-terminates the destination, and it doesn't write any extra nulls.
I use this:<p><pre><code> char* scatn(char* ss, …);
#define scat(args...) scatn(args, 0)
char* scatn(char* ss, ...)
{
char *s;
char *new;
size_t len;
size_t n;
va_list ap;
/* first find the lengths of the strings */
va_start(ap, ss);
s = ss;
len = 0;
while(s != 0){
len = len + strlen(s);
s=va_arg(ap, char *);
}
va_end(ap);
/* make a buffer big enough for all strings + '\0" */
new = (char *) malloc(sizeof(char) * (len + 1));
if(new == NULL){
perror("Out of memory");
exit(EXIT_FAILURE);
}
/* copy the strings into the buffer */
va_start(ap, ss);
s = ss;
n = 0;
while(s != 0){
len = strlen(s);
memcpy(new+n,s,len);
n = n + len;
s=va_arg(ap, char *);
}
va_end(ap);
/* terminate the string */
new[n]='\0';
/* return the string: remember to free it! */
return new;
}
</code></pre>
use like this:<p><pre><code> s = scat("hello","hacker","news");
:
free(s);
</code></pre>
I did have a version with only one loop and realloc but it turned out to be twice as quicker to go through each string twice. I have no idea why :)
Yeah, don't use cstrings. If you're using C, use bstrings. If you're using C++, use std::string. Ignore the extra three bytes of memory overhead and enjoy the extra safety.
'that is what the libc runtime, which is the foundation that every language ultimately reaches down to in the end, is built around.'<p>Except, interestingly enough, Go code compiled with the standard compilers (5g, 6g, 8g, see <a href="http://golang.org/doc/go_faq.html#How_is_the_run_time_support_implemented" rel="nofollow">http://golang.org/doc/go_faq.html#How_is_the_run_time_suppor...</a>). The Plan9 expats are hell-bent on doing things their own way, I am 70% in agreement with them :).
Deficiencies in strl aside, most C programmers do not realize the target-padding that is going on with the strn family. Discussion is always good, but it will be much more of an uphill battle to introduce new routines than it would be to get strn users to use strl. I've seen too many people bitten by declaring something like:<p><pre><code> char buf[65536]; /* 64k is enough for everything! */
</code></pre>
and using strncpy w/ sizeof(buf) to populate it.
Oh neat, thanks for posting this.<p>I should note that I usually write articles to kick off discussions on my own forum, and then revise them after all input is gathered. They almost never appear on other sites, especially pre-revision.<p>I'm not saying the strmcpy/cat functions there now are the best solution, and I'm open to hearing what's wrong with them so that we can improve upon them.
The best system involves keeping end pointers, not lengths. Remaining length changes. End pointer never changes. At previous job we converted our whole code base to this system, and it worked great.