On Tue, 15 Apr 2008 01:26:40 +0200, Mel <[EMAIL PROTECTED]> wrote: > On Tuesday 15 April 2008 01:06:24 Giorgos Keramidas wrote: >> On Mon, 14 Apr 2008 15:43:24 -0700, "Steve Franks" <[EMAIL PROTECTED]> > wrote: >> > I'm getting an undefined reference to strndup, so clearly there's a >> > header somewhere with it - doesn't seem to be in my default libc, >> > however on 7.0-amd64? >> >> I don't see an strndup() function in our libc. >> >> [EMAIL PROTECTED]:/usr/src/lib/libc/string$ grep ^strdup *.c >> strdup.c:strdup(str) >> [EMAIL PROTECTED]:/usr/src/lib/libc/string$ grep ^strndup *.c >> [EMAIL PROTECTED]:/usr/src/lib/libc/string$ >> >> While it seems like a cool function name, what's the point of having it? >> If you know how much you want to copy, it's trivial to allocate a buffer >> large enough and strlcpy() into it. If you don't know how much you want >> to copy, then strdup() is ok anyway :) > > It can be convenient for trickery: > char file[MAXPATHLEN]; > char *dir; > ... > dir = strndup(file, (strrchr(file, '/')-file)));
I know, but I don't feel safe when I see code like this. All sorts of amusing things can happen when it's used this way and strrchr() returns NULL though, so it is safer to explicitly allocate buffers and check what's going on. > Or space optimization: > char *p, *path; > path = malloc(MAXPATHLEN); > (void)strlcpy(path, argv[i], MAXPATHLEN); > p = strndup(path, strlen(path)); > free(path); > > But, personally I prefer taking the long route or wasting a few bytes > over dual allocations. I can definitely agree with this part :) _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
