From the dmalloc mailing list:


	I ran into problems with dmalloc 4.8.2 and strdup.

Specifically, on my system (a Red Hat Linux system),
strdup() becomes a very complex macro, that can
either resolve into a call to malloc/memcpy or
into a call to __strdup.

The full macro looks like this:

#  define __strdup(s) \
   (__extension__ (__builtin_constant_p (s) && __string2_1bptr_p (s)
        \
         ? (((__const char *) (s))[0] == '\0'                        \
         ? (char *) calloc (1, 1)                                 \
              : ({ size_t __len = strlen (s) + 1;                      \
                char *__retval = (char *) malloc (__len);           \
                  if (__retval != NULL)                               \
                      __retval = (char *) memcpy (__retval, s, __len);  \
                  __retval; }))                                       \
           : __strdup (s)))


Now, the configure test determines that strdup
is a macro, and turns on DMALLOC_STRDUP_MACRO.

This basically means that in the case that we call
__strdup, we lose the memory allocation, and
all subsequent free calls appear as errors.

Turning off DMALLOC_STRDUP_MACRO manually causes
compilation errors (when we prototype strdup).

So, I guess the question is, how best to fix this?

The approach I'm planning on is to turn on
__NO_STRING_INLINES in my configure script (when dmalloc is selected),
which disables this behaviour in bits/string2.h.

Anyone have a better idea?