strdup() function

问题:

I recently became aware that the strdup() function I've enjoyed using so much on OS X is not part of ANSI C, but part of POSIX. I don't want to rewrite all my code, so I think I'm just going to write my own strdup() function. It's not that hard, really, it's just a malloc() and a strcpy(). Anyway, I have the function, but what am I doing if I write this function and link it to my code, and it already exists in the libc? Will my linker or compiler allow me to basically define my own version of the function, or do I have to give it another name? It would be terribly convenient if there was a way to reuse the same name, so that if strcpy() exists in the user's libc they could use that, but if it didn't exist in their libc they could use my version instead, with as little code change as possible.

The short version:

a) What happens when I write my own function with the same name as a built-in function?

b) What can I do to avoid bad things happening to me on platforms that don't have strdup() without rewriting all my code to not use strdup(), which is just a bit tedious?

回答1:

Usually, you just use an #if to define the function you want when under a certain compiler. If the built-in library doesn't define strdup, there is no problem in defining it yourself (other than if they do define it in the future, you'll have to take it out.)

// Only define strdup for platforms that are missing it..
#if COMPILER_XYZ || COMPILER_ABC
char *strdup(const char *)
{
   // ....
}
#endif

回答2:

you could just use a macro like this, this way you can use the old name, but linker will see a different name;

char *my_strdup(const char *s) {
    char *p = malloc(strlen(s) + 1);
    if(p) { strcpy(p, s); }
    return p;
}

/* this goes in whatever header defines my_strdup */
char *my_strdup(const char *s);
#define strdup(x) my_strdup(x)

回答3:

As Rob Kennedy noted the best way is to test inside your building scripts if this functions exists or not. I know that it is fairly easy with autoconfig, but probably with other cross-platform building scripts tools, too.

Then you simply place in your header file:

#ifndef HAVE_STRDUP
# ifdef HAVE__STRDUP
#  define strdup _strdup
# else
#  define strdup my_strdup
# endif
#endif

If strdup already exists on the target platform the libc version is used, if not your custom my_strdup function will be used.

EDIT: I should have added an explination why it is better.

First the compiler is unrelated to the existence of a function in the libc. For example take the function strlcpy. It is present on FreeBSD but not on Linux (glibc), although both are using gcc by default. Or what happens if someone is going to compile your code with clang?

Second a platform check (I don't know if there is a standard way) will only work if you explicitly add for every plattform you want to support the correct preprocessor conditional. So assuming you have mastered to compile your application on OSX and Win32 and you want to compile it now on Linux, you'll have to go through all preprocessor conditionals to see if they work for Linux. Maybe you also want to support FreeBSD, OpenBSD, etc.? Same work again. With a test in your building scripts, it may compile without any additional work.

回答4:

a) What happens when I write my own function with the same name as a built-in function?

You cannot re-define a function that already exists in a header file you are including. This will result in a compilation error.

b) What can I do to avoid bad things happening to me on platforms that don't have strdup() without rewriting all my code to not use strdup(), which is just a bit tedious?

I would recommend creating your own wrapper function to strdup, and replacing all your calls to use the new wrapper function. For example:

char *StringDuplicate(const char *s1)
{
#ifdef POSIX
    return strdup(s1);
#else
    /* Insert your own code here */
#endif
}

Changing all your calls from strdup to StringDuplicate() should be a simple find-and-replace operation, making it a feasible approach. The platform-specific logic will then be kept in a single location rather than being scattered throughout your codebase.

回答5:

You should also consider avoiding the creation of any identifier (including a function) that begins with str[a-z]. While this isn't reserved, the C standard (ISO/IEC 9899:1999) section 7.26.11 (future library directions) states "Function names that begin with str, mem, or wcs and a lowercase letter may be added to the declarations in the header."

回答6:

FYI: I've never personally seen an environment that did not define strdup().

回答7:

If anyone else reads this: Don't use a platform's strdup() even if available, and don't waste time/effort with autoconf/automake just to use it. Seriously, how hard is this:

char* mystrdup(const char* str)
{
 return strcpy(malloc( strlen(str) + 1),str);
}

Does this really warrant #ifdefs? Compiler checks? K.I.S.S.