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

This is a discussion on Compiler error: warning: implicit declaration of function 'strdup' within the C Programming forums, part of the General Programming Boards category; Hi guys, When I compile this code, I'm getting the following error: warning: implicit declaration of function 'strdup' I've included ...

  1. #1
    Registered User
    Join Date
    Nov 2007
    Posts
    23

    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

  2. #2
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,158
    Quote Originally Posted by TalonStriker View Post
    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;
    }

  3. #3
    Registered User
    Join Date
    Nov 2007
    Posts
    23
    Well I'm using the gcc compiler.

    Quote Originally Posted by brewbuck View Post
    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

  4. #4
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,158
    Quote Originally Posted by TalonStriker View Post
    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.

  5. #5
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  6. #6
    Registered User
    Join Date
    Nov 2007
    Posts
    23
    Quote Originally Posted by matsp View Post
    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)?

  7. #7
    Registered User
    Join Date
    Nov 2007
    Posts
    23
    Quote Originally Posted by brewbuck View Post
    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?

  8. #8
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  9. #9
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,158
    Quote Originally Posted by TalonStriker View Post
    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.

  10. #10
    Registered User ssharish2005's Avatar
    Join Date
    Sep 2005
    Location
    Cambridge, UK
    Posts
    1,682
    Have a look at this thread which has a draft copy of C standard C89 C99 ...
    C Standards

    ssharish

  11. #11
    Registered User
    Join Date
    Nov 2007
    Posts
    23
    Quote Originally Posted by ssharish2005 View Post
    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.

  12. #12
    Registered User
    Join Date
    Nov 2007
    Posts
    23
    Quote Originally Posted by brewbuck View Post
    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?

  13. #13
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Last edited by matsp; 11-10-2007 at 12:28 PM.
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  14. #14
    Registered User
    Join Date
    Nov 2007
    Posts
    23
    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, "&#37;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

  15. #15
    Registered User
    Join Date
    Nov 2007
    Posts
    23
    actually, nevermind. I foud the bug... The valgrind error info was pointing at the spot where I allocated memory--ot where the leak occured.
    Last edited by TalonStriker; 11-11-2007 at 06:01 AM.

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Undefined Reference Compiling Error
    By AlakaAlaki in forum C++ Programming
    Replies: 1
    Last Post: 06-27-2008, 11:45 AM
  2. Replies: 2
    Last Post: 11-08-2007, 01:33 AM
  3. Replies: 12
    Last Post: 10-24-2007, 08:10 AM
  4. Replies: 28
    Last Post: 07-16-2006, 11:35 PM
  5. Problem with Visual C++ Object-Oriented Programming Book.
    By GameGenie in forum C++ Programming
    Replies: 9
    Last Post: 08-29-2005, 11:21 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21