[?OT?] strndup exists in FreeBSD?

[Giorgos Keramidas]

On Tue, 15 Apr 2008 01:26:40 +0200, Mel <fbsd.questions at rachie.is-a-geek.net> wrote:
> On Tuesday 15 April 2008 01:06:24 Giorgos Keramidas wrote:
>> On Mon, 14 Apr 2008 15:43:24 -0700, "Steve Franks" <stevefranks at ieee.org> 
> 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.
>>
>> keramida at kobe:/usr/src/lib/libc/string$ grep ^strdup *.c
>> strdup.c:strdup(str)
>> keramida at kobe:/usr/src/lib/libc/string$ grep ^strndup *.c
>> keramida at kobe:/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 :)