Thread: Compiler error: warning: implicit declaration of function 'strdup'

Originally Posted by TalonStriker

I've included <string.h> and <wchar.h> so I shouldn't be getting the error right?

I've seen environments where strdup() was declared in stdlib.h instead of string.h where it was supposed to be.

Alternatively, you could be banging up against Microsoft's stupid attempts to "make C secure," by deprecating basic language functions. Do you happen to be compiling with a MS compiler?

EDIT: Haha, nevermind. I forgot that strdup() isn't standard C, so if your compiler doesn't support it... That's tough. Write it yourself:

Code:

char *strdup(const char *str)
{
    int n = strlen(str) + 1;
    char *dup = malloc(n);
    if(dup)
    {
        strcpy(dup, str);
    }
    return dup;
}

Well I'm using the gcc compiler.

Originally Posted by brewbuck

EDIT: Haha, nevermind. I forgot that strdup() isn't standard C, so if your compiler doesn't support it... That's tough. Write it yourself:

Code:

char *strdup(const char *str)
{
    int n = strlen(str) + 1;
    char *dup = malloc(n);
    if(dup)
    {
        strcpy(dup, str);
    }
    return dup;
}

Thanks. I'm not sure why strdup() not being in standard C effects anything. According to the gcc API, strdup is supported in gcc. However, I'm compiling with the ansi and pedantic flags--does this somehow exclude the strdup() from being #include'd when I include string.h?

Anyways thanks for the implementation of strdup...I was afraid that I'd have to waste brain cells writing my own strdup

Originally Posted by TalonStriker

Thanks. I'm not sure why strdup() not being in standard C effects anything.

Because if it's not standard, then there is no standard place where the prototype will live. On my gcc installation here, strdup() is defined in string.h. On yours, it clearly is not. Is that not enough to convince you that non-standard features are, in fact, non-standard?

According to the gcc API, strdup is supported in gcc. However, I'm compiling with the ansi and pedantic flags--does this somehow exclude the strdup() from being #include'd when I include string.h?

That MIGHT have something to do with it. Not sure though.

Originally Posted by matsp

It won't make errors of it unless you use -Werror [which will make errors of all warnings]--
Mats

Ah... I see... suppose I hadn't used -Werror, it would have created the object code...but would that object code be "wrong" (i.e. not run properly after linking)?

Originally Posted by brewbuck

Because if it's not standard, then there is no standard place where the prototype will live. On my gcc installation here, strdup() is defined in string.h. On yours, it clearly is not. Is that not enough to convince you that non-standard features are, in fact, non-standard?

Actually, I didn't quite understand what "standard" meant in this context. From your explanation, for a function to be standard, its prototype should exist in the same library in all compilers....or am I jumping to conclusions?

Originally Posted by TalonStriker

Actually, I didn't quite understand what "standard" meant in this context. From your explanation, for a function to be standard, its prototype should exist in the same library in all compilers....or am I jumping to conclusions?

For a function to be standard, it must be described in the document ISO-9899 (i.e. the "C standard"). That's what I mean.

Originally Posted by brewbuck

Code:

char *strdup(const char *str)
{
    int n = strlen(str) + 1;
    char *dup = malloc(n * sizeof(char));
    if(dup)
    {
        strcpy(dup, str);
    }
    return dup;
}

I'm using this implementation of strdup. When I was checking whether I had any memory leaks, the compiler claims that there is a memory leak at line 4 of the function.

Code:

1179            char *dup = malloc(n * sizeof(char));
(gdb) next
memory clobbered past end of allocated block

Any idea how that could happen?