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

Hi guys,

When I compile this code, I'm getting the following error:
warning: implicit declaration of function 'strdup'

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

The line of code in question is:

Code:

---

//some declarations inside a static function
simple_path = strdup(path);

---

Any help is appreciated.

Thanks


EDIT: Here's a entire function until the point of the error:

Code:

---

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <wchar.h>
 
/* some other functions*/
 
static Item * parse(Item * const root, Item * const curr, char * path)
{
    char *simple_path;
    char *a, *b;
    char temp[80] = {0};
    Item * true_item = NULL;
    int finished = 0;
   
    simple_path = strdup(path); //error here
//blah blah

---

Quote:

---

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.

Quote:

---

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 :)

Quote:

---

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?

Quote:

---

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.

Yes, if you compile with -ansi the compiler will not use non-standard functions, and if you compile with -pedantic it will also warn about some non-standard behaviours in the code you write. It won't make errors of it unless you use -Werror [which will make errors of all warnings]

--
Mats

Quote:

---

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)?

Quote:

---

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?

Possibly. I actually would recommend using -Werror for new projects - it may not work on old projects which already have warnings [or if you dramatically change the compiler version, e.g. changing from a 3.4 to a 4.2 version of gcc may throw a few new warnings in the mix, and in a large project that could cause major issues - of course, changing the compiler on large pieces of code is always a "interesting" project]

--
Mats

Quote:

---

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.

Have a look at this thread which has a draft copy of C standard C89 C99 ...
C Standards

ssharish

Quote:

---

Originally Posted by ssharish2005

Have a look at this thread which has a draft copy of C standard C89 C99 ...
C Standards

ssharish

---

I see that strdup isn't on the list :(

Heh, I learned more out of this ordeal that I bargained for.

Quote:

---

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?

I don't see anything wrong with that line itself. Perhaps the REAL problem is elsewhere, but this is where it gets detected? What code runs just before this, and does it stick within it's allowed limits?

Edit: It looks like your error message comes from the call to malloc() itself, rather than strdup(). I strongly suspect (as posted above) that this is part of "selfchecking" inside malloc that says "is the header that I'm using to allocate the next block of memory OK or not", and if it's NOT OK, it prints the above message. I have no idea how your particular malloc works, but most malloc functions keep it's own little structure before the actual address you get back from malloc. The data structure often contains some way to determine that it's correct, such as a "magic" value that should match either a constant, or some other data in the block in some way - e.g. the first element is a pointer to the next block of memory. After this pointer, we may for example store the inverse of that pointer, just to check. Or the first element should always be 0xaa55baba. If that doesn't "match up" then the malloc function says "what the **** is going on here"...

--
Mats

Well it's called from the first line of get_trailer(char *), and I'm passing the results of this code into get_trailer()

Code:

---

sscanf(command_string, "%s %s", command, arg1); //command_string is read-in from stdin
                       
                        prefix1 = get_prefix(arg1);
                        trailer1 = get_trailer(arg1);

---

Whatever the error is, I doubt it is in get_trailer because get_trailer just passes its parameter into strdup

actually, nevermind. I foud the bug... The valgrind error info was pointing at the spot where I allocated memory--ot where the leak occured.