strdup() function

Question

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

Answer 1

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.

Answer 2

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.

Answer 3

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

Answer 4

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.

Answer 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."

Answer 6

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